Evolved data compression scheme signaling

ABSTRACT

Methods, systems, and devices are described for wireless communication at a UE. In aspects, a receiver may receive a transmission requesting information about support for data compression. The receiver may determine parameters related to the types of supported data compression and communicate the information to the transmitting device. In some cases, the receiver may then receive a message from the transmitting entity that requests establishment of a data compression configuration. The receiver may respond with confirmation or rejection of the proposed compression configuration. If the configuration is confirmed, the transmitter and receiver may exchange compressed data packets according to the configuration. The devices may exchange status and control information related to the compression configuration (e.g., in a compression header of a compressed message or a separate status and/or control information message).

CROSS REFERENCES

The present application for patent claims priority to U.S. ProvisionalPatent Application No. 62/151,371 by Raina et al., entitled “EvolvedData Compression Scheme Signaling,” filed Apr. 22, 2015, U.S.Provisional Patent Application No. 62/121,433 by Maheshwari et al.,entitled “Techniques For Extending A Header For An Evolved DataCompression Scheme (EDCS),” filed Feb. 26, 2015, U.S. Provisional PatentApplication No. 62/080,197 by Raina et al., entitled “Evolved DataCompression Scheme Signaling,” filed Nov. 14, 2014, and U.S. ProvisionalPatent Application No. 62/080,227 by Dalmiya et al., entitled“Techniques For Extending A Header For An Evolved Data CompressionScheme (EDCS),” filed Nov. 14, 2014, assigned to the assignee hereof.

BACKGROUND

Field of Disclosure

The following relates generally to wireless communication, and morespecifically to evolved data compression scheme signaling.

Description of Related Art

Wireless communications systems are widely deployed to provide varioustypes of communication content such as voice, video, packet data,messaging, broadcast, and so on. These systems may be multiple-accesssystems capable of supporting communication with multiple users bysharing the available system resources (e.g., time, frequency, andpower). Examples of such multiple-access systems include code divisionmultiple access (CDMA) systems, time division multiple access (TDMA)systems, frequency division multiple access (FDMA) systems, andorthogonal frequency division multiple access (OFDMA) systems, (e.g., aLong Term Evolution (LTE) system).

By way of example, a wireless multiple-access communications system mayinclude a number of base stations, each simultaneously supportingcommunication for multiple communication devices, which may be otherwiseknown as user equipment (UEs). A base station may communicate with thecommunication devices on downlink channels (e.g., for transmissions froma base station to a UE) and uplink channels (e.g., for transmissionsfrom a UE to a base station).

Wireless systems may suffer from congestion due to an increasing numberof receivers and an increasing amount of data traffic to and from thosereceivers. Increased congestion may result in slower communicationexchanges, and may also result in difficulties establishing connectionsbetween receivers and transmitters. Receivers may spend a significantlyhigher amount of time searching for available base stations or waitingin an active state for communications, thus representing a power drainon the receiver.

A wireless communications system may use data acceleration techniquessuch as data compression to relieve congestion. Data compression mayreduce the amount of resources it takes to transmit information.However, the transmitter may not know what configurations of datacompression the receiver supports. Consequently, the transmitter may usea data compression configuration which the receiver does not support, ormay forego using data compression altogether, which may result indecreased communication performance.

SUMMARY

The present disclosure may relate generally to wireless communicationssystems, and more particularly to improved systems, methods, orapparatuses for evolved data compression scheme signaling. For example,a receiver may receive a transmission requesting information aboutsupport for data compression. The receiver may determine parametersrelated to the types of supported data compression and communicate theinformation to the transmitting device. In some cases, the receiver maythen receive a message from the transmitting entity that requestsestablishment of a data compression configuration. The receiver mayrespond with confirmation or rejection of the proposed compressionconfiguration. If the configuration is confirmed, the transmitter andreceiver may exchange compressed data packets according to theconfiguration. The devices may also exchange status and controlinformation related to the compression configuration (e.g., in acompression header of a compressed message or a separate status and/orcontrol information message).

One example for reducing congestion in wireless communication networksis to apply compression schemes to the wireless communications. Anexample compression scheme may be referenced herein as an evolved datacompression scheme (eDCS). eDCS is a compression scheme that may be usedby both receivers and transmitters. In order to use eDCS, however, boththe receivers and the transmitters may require access to a compressioncontext. The compression context provides the receivers and thetransmitters the compression scheme that is to be or has been applied.Thus, a compression context may vary based on different types of trafficand payloads on a wireless communication network. The compressioncontext, and other useful compression options, may be communicatedbetween a receiver and a transmitter using, for example, a compressionheader. The compression header may include a compression scheme portionhaving an extension indicator to indicate that the compression headerincludes various compression options, such as implementation of variouscompression contexts.

A method of wireless communication at a UE is described. The method mayinclude receiving a compression capability request related to acapability for compressing a payload of a wireless data transmission,identifying at least one compression capability parameter based on thecompression capability request, and transmitting a compressioncapability response based at least in part on the compression capabilityrequest and the at least one compression capability parameter.

An apparatus for wireless communication at a UE is described. Theapparatus may include means for receiving a compression capabilityrequest related to a capability for compressing a payload of a wirelessdata transmission, means for identifying at least one compressioncapability parameter based on the compression capability request, andmeans for transmitting a compression capability response based at leastin part on the compression capability request and the at least onecompression capability parameter.

A further apparatus for wireless communication at a UE is described. Theapparatus may include a processor, memory in electronic communicationwith the processor, and instructions stored in the memory, wherein theinstructions are executable by the processor to receive a compressioncapability request related to a capability for compressing a payload ofa wireless data transmission, identify at least one compressioncapability parameter based on the compression capability request, andtransmit a compression capability response based at least in part on thecompression capability request and the at least one compressioncapability parameter.

A non-transitory computer-readable medium storing code for wirelesscommunication at a UE is described. The code may include instructionsexecutable to receive a compression capability request related to acapability for compressing a payload of a wireless data transmission,identify at least one compression capability parameter based on thecompression capability request, and transmit a compression capabilityresponse based at least in part on the compression capability requestand the at least one compression capability parameter.

Some examples of the method, apparatuses, or non-transitorycomputer-readable medium described above may further include receiving acompression configuration request. Additionally or alternatively, someexamples may include transmitting a compression configurationconfirmation based at least in part on the compression configurationrequest.

Some examples of the method, apparatuses, or non-transitorycomputer-readable medium described above may further includetransmitting a compression configuration rejection based at least inpart on the compression configuration request. Additionally oralternatively, some examples may include transmitting a compressedpacket based at least in part on the compression capability response.

Some examples of the method, apparatuses, or non-transitorycomputer-readable medium described above may further include receiving acompressed packet based at least in part on the compression capabilityresponse. Additionally or alternatively, in some examples the compressedpacket comprises one or more extended compression header fieldsindicating at least one of a compression context reset request, acompression disable request associated with a number of subsequentpackets, a compression context synchronization indication, a compressioncontext freeze request, a multi-part compression indicator associatedwith a plurality of compression contexts, or a compression metadataindicator.

Some examples of the method, apparatuses, or non-transitorycomputer-readable medium described above may further includetransmitting a context identification (ID) save confirmation request.Additionally or alternatively, some examples may include receiving acontext ID save confirmation.

Some examples of the method, apparatuses, or non-transitorycomputer-readable medium described above may further includetransmitting a compression control message (e.g., request). Additionallyor alternatively, in some examples transmitting the compression controlmessage comprises transmitting the compression control message on a highpriority radio bearer.

In some examples of the method, apparatuses, or non-transitorycomputer-readable medium described above, the compression controlmessage is based at least in part on a determination that an amount ofavailable wireless device processing resources is below a threshold.Additionally or alternatively, in some examples the compression controlmessage is based on a determination that the wireless device has failedto decompress or decode a number of packets.

In some examples of the method, apparatuses, or non-transitorycomputer-readable medium described above, the compression controlmessage comprises at least one of a compression state indication, acompression scope indication, a data compression threshold, acompression enable/disable indication, a compressed packet ratio, or acontext ID reset request. Additionally or alternatively, some examplesmay include transmitting a compression status indication.

In some examples of the method, apparatuses, or non-transitorycomputer-readable medium described above, the compression statusindication comprises at least one of a ciphered packet data convergenceprotocol (PDCP) control protocol data unit (PDU) type, an uncipheredPDCP control PDU type, a sequence number, a compression enable/disableindication. In some examples of the method, apparatuses, ornon-transitory computer-readable medium described above, transmittingthe compression status indication comprises disabling or enablingcompression on a radio bearer, and transmitting the compression statusindication after a last or before a first compressed data protocol dataunit (PDU) is transmitted. Additionally or alternatively, some examplesmay include transmitting a compression enable request or a compressiondisable request based at least in part on at least one of a processinglimitation, a traffic type, or a determination that a resource grantvolume is sufficient to clear an uncompressed memory buffer during oneor more periodic intervals.

In some examples of the method, apparatuses, or non-transitorycomputer-readable medium described above, the compression capabilityparameter comprises a compression rate support parameter or acompression context prefill configuration. Additionally oralternatively, some examples may include disabling a PDCP discard timerbased at least in part on the compression capability request.

Some examples of the method, apparatuses, or non-transitorycomputer-readable medium described above may further include receiving acompressed packet, wherein the compressed packet is compressedimmediately prior to transmission. Additionally or alternatively, someexamples may include resetting a compression queue based on anindication that a compressed packet has been dropped.

Some examples of the method, apparatuses, or non-transitorycomputer-readable medium described above may further include storing acompressed version of a packet, storing an uncompressed version of thepacket, and resetting a context ID based on the uncompressed version ofthe packet.

A method of wireless communication at a base station is described. Themethod may include transmitting a compression capability request relatedto a capability for compressing a payload of a wireless datatransmission, receiving a compression capability response based at leastin part on the compression capability request, and selecting acompression configuration based at least in part on the compressioncapability response.

An apparatus for wireless communication at a base station is described.The apparatus may include means for transmitting a compressioncapability request related to a capability for compressing a payload ofa wireless data transmission, means for receiving a compressioncapability response based at least in part on the compression capabilityrequest, and means for selecting a compression configuration based atleast in part on the compression capability response.

A further apparatus for wireless communication at a base station isdescribed. The apparatus may include a processor, memory in electroniccommunication with the processor, and instructions stored in the memory,wherein the instructions are executable by the processor to transmit acompression capability request related to a capability for compressing apayload of a wireless data transmission, receive a compressioncapability response based at least in part on the compression capabilityrequest, and select a compression configuration based at least in parton the compression capability response.

A non-transitory computer-readable medium storing code for wirelesscommunication at a base station is described. The code may includeinstructions executable to transmit a compression capability requestrelated to a capability for compressing a payload of a wireless datatransmission, receive a compression capability response based at leastin part on the compression capability request, and select a compressionconfiguration based at least in part on the compression capabilityresponse.

Some examples of the method, apparatuses, or non-transitorycomputer-readable medium described above may further includetransmitting a compression configuration request based at least in parton the selected compression configuration. Additionally oralternatively, some examples may include receiving a compressionconfiguration confirmation based at least in part on the compressionconfiguration request.

Some examples of the method, apparatuses, or non-transitorycomputer-readable medium described above may further include receiving acompression configuration rejection based at least in part on thecompression configuration request. Additionally or alternatively, someexamples may include receiving a compressed packet based at least inpart on the compression capability response.

Some examples of the method, apparatuses, or non-transitorycomputer-readable medium described above may further includetransmitting a compressed packet based at least in part on thecompression capability response. Additionally or alternatively, in someexamples the compressed packet comprises one or more extendedcompression header fields indicating at least one of a compressioncontext reset request, a compression disable request associated with anumber of subsequent packets, a compression context synchronizationindication, a compression context freeze request, a multi-partcompression indicator associated with a plurality of compressioncontexts, or a compression metadata indicator.

Some examples of the method, apparatuses, or non-transitorycomputer-readable medium described above may further include receiving acontext ID save confirmation request. Additionally or alternatively,some examples may include transmitting a context ID save confirmation.

Some examples of the method, apparatuses, or non-transitorycomputer-readable medium described above may further includetransmitting a compression control message (e.g., request). Additionallyor alternatively, in some examples transmitting the compression controlmessage comprises transmitting the compression control message on a highpriority radio bearer.

In some examples of the method, apparatuses, or non-transitorycomputer-readable medium described above, the compression controlmessage is based at least in part on a determination that an amount ofavailable wireless device processing resources is below a threshold.Additionally or alternatively, in some examples the compression controlmessage is based on a determination that the wireless device has failedto decompress or decode a number of packets.

In some examples of the method, apparatuses, or non-transitorycomputer-readable medium described above, the compression controlmessage comprises at least one of a compression state indication, acompression scope indication, a data compression threshold, acompression enable/disable indication, a compressed packet ratio, or acontext ID reset request. Additionally or alternatively, some examplesmay include transmitting a compression status indication.

In some examples of the method, apparatuses, or non-transitorycomputer-readable medium described above, the compression statusindication comprises at least one of a ciphered PDCP control PDU type,an unciphered PDCP control PDU type, a sequence number, or a compressionenable/disable indication. Additionally or alternatively, some examplesmay include transmitting a compression enable request or a compressiondisable request based at least in part on at least one of a processinglimitation, a traffic type, or a determination that a resource grantvolume is sufficient to clear an uncompressed memory buffer during oneor more periodic intervals.

In some examples of the method, apparatuses, or non-transitorycomputer-readable medium described above, the capability relates to acompression rate support parameter or a compression context prefillconfiguration. Additionally or alternatively, some examples may includedisabling a PDCP discard timer based at least in part on the compressioncapability request.

Some examples of the method, apparatuses, or non-transitorycomputer-readable medium described above may further include resetting acompression queue based on an indication that a compressed packet hasbeen dropped. Additionally or alternatively, some examples may includedetermining that a packet is scheduled for immediate transmission, andcompressing the packet based on the determination that the packet isscheduled for immediate transmission.

A method for wireless communication is described. The method may includeidentifying a compression option associated with a wirelesscommunication session, wherein the compression option is associated withat least a compression context in the wireless communication session.The method may also include generating a compression header for a datapacket, wherein the compression header comprises a compression schemeportion that identifies the compression option. Additionally, the methodmay include transmitting the compression header and the data packetduring the wireless communication session.

An apparatus for wireless communication is described. The apparatus mayinclude means for identifying a compression option associated with awireless communication session, wherein the compression option isassociated with at least a compression context in the wirelesscommunication session. The apparatus may also include means forgenerating a compression header for a data packet, wherein thecompression header comprises a compression scheme portion thatidentifies the compression option. The apparatus may further includemeans for transmitting the compression header and the data packet duringthe wireless communication session.

A further apparatus for wireless communication is described. Theapparatus may include a processor, memory in electronic communicationwith the processor, and instructions stored in the memory. Theinstructions may be executable by the processor to identify acompression option associated with a wireless communication session,wherein the compression option is associated with at least a compressioncontext in the wireless communication session. The instructions mayfurther be executable by the processor to generate a compression headerfor a data packet, wherein the compression header comprises acompression scheme portion that identifies the compression option. Theinstructions may further be executable by the processor to transmit thecompression header and the data packet during the wireless communicationsession.

A non-transitory computer-readable medium storing computer-executablecode for wireless communication is described. The code may be executableby a processor to identify a compression option associated with awireless communication session, wherein the compression option isassociated with at least a compression context in the wirelesscommunication session. The code may further be executable by a processorto generate a compression header for a data packet, wherein thecompression header comprises a compression scheme portion thatidentifies the compression option. The code may also be executable by aprocessor to transmit the compression header and the data packet duringthe wireless communication session.

Some examples of the method, apparatuses, or non-transitorycomputer-readable medium described above may further include conveying,via the compression option, a compression context identification (ID)which identifies the compression context applied to one or more portionsof the data packet. Additional examples may include indicating to areceiver, via the compression option, to reset a compression scheme to acompression context ID. Other examples may include indicating to areceiver, via the compression option, to store the compression contextusing the compression context ID. Some examples may include indicatingto a receiver, via the compression option, to apply the compressioncontext ID to additional data packets transmitted subsequent to thetransmission of the data packet without updating the compressioncontext. Other examples may include indicating, via the compressionoption, that the compression context ID applies to a part of anun-compressed portion of the data packet. The part to which thecompression context ID applies may be indicated by a length of thatpart. The length of the part may be indicated with the compressioncontext ID or via a separate length indicator field. Alternatively, thepart to which the compression context ID applies may be indicated by anabsence of a length field indicating a length of that part, wherein thepart is a remaining portion of the data packet.

Some examples of the method, apparatuses, or non-transitorycomputer-readable medium described above may further include indicating,via the compression option, that at least one data packet transmittedsubsequent to the transmission of the data packet will not include thecompression header. Other examples may include indicating, via thecompression option, that current and subsequent data packets will notinclude a compression metadata. Still other examples may includepre-negotiating a compression context identification (ID) and acorresponding compressed portion of the data packet; and using thecompression scheme portion to indicate that the compression option is anull value.

Some examples of the method, apparatuses, or non-transitorycomputer-readable medium described above may further include using thecompression option to indicate a compression context identification (ID)and a corresponding compressed portion of the data packet. Thecorresponding compressed portion of the data packet may be indicated bya length of the corresponding compressed portion. The length may beindicated in a dedicated length field indicator of the compressionoption.

Still other examples of the method, apparatuses, or non-transitorycomputer-readable medium described above may further include using thecompression option to indicate a plurality of compression contextidentifications (IDs) and corresponding compressed portions of the datapacket. At least one of the corresponding compressed portions may be asession initiation protocol (SIP). At least one of the correspondingcompressed portions may be a TCP/IP header.

The foregoing has outlined rather broadly the features and technicaladvantages of examples according to the disclosure in order that thedetailed description that follows may be better understood. Additionalfeatures and advantages will be described hereinafter. The conceptionand specific examples disclosed may be readily utilized as a basis formodifying or designing other structures for carrying out the samepurposes of the present disclosure. Such equivalent constructions do notdepart from the scope of the appended claims. Characteristics of theconcepts disclosed herein, both their organization and method ofoperation, together with associated advantages will be better understoodfrom the following description when considered in connection with theaccompanying figures. Each of the figures is provided for the purpose ofillustration and description only, and not as a definition of the limitsof the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

A further understanding of the nature and advantages of the presentdisclosure may be realized by reference to the following drawings. Inthe appended figures, similar components or features may have the samereference label. Further, various components of the same type may bedistinguished by following the reference label by a dash and a secondlabel that distinguishes among the similar components. If just the firstreference label is used in the specification, the description isapplicable to any one of the similar components having the same firstreference label irrespective of the second reference label.

FIG. 1 illustrates an example of a wireless communications system forevolved data compression scheme signaling in accordance with variousaspects of the present disclosure.

FIG. 2 illustrates an example of a wireless communications subsystem forevolved data compression scheme signaling in accordance with variousaspects of the present disclosure.

FIG. 3A illustrates an example of an extended compression headerassociated with data for evolved data compression scheme signaling inaccordance with various aspects of the present disclosure.

FIG. 3B illustrates another example of an extended compression headerassociated with data for evolved data compression scheme signaling inaccordance with various aspects of the present disclosure.

FIG. 4 illustrates an example of a process flow for evolved datacompression scheme signaling in accordance with various aspects of thepresent disclosure.

FIG. 5 illustrates an example of a process flow for evolved datacompression scheme signaling in accordance with various aspects of thepresent disclosure.

FIG. 6A, FIG. 6B, and FIG. 6C show examples of a compression header forevolved data compression scheme signaling in accordance with variousaspects of the present disclosure.

FIG. 7A and FIG. 7B show examples of a compression header for evolveddata compression scheme signaling in accordance with various aspects ofthe present disclosure.

FIG. 8 shows an example of a compression header for evolved datacompression scheme signaling in accordance with various aspects of thepresent disclosure.

FIG. 9 shows a block diagram of a wireless device configured for evolveddata compression scheme signaling in accordance with various aspects ofthe present disclosure.

FIG. 10 shows a block diagram of a wireless device configured forevolved data compression scheme signaling in accordance with variousaspects of the present disclosure.

FIG. 11 shows a block diagram of an evolved data compression moduleconfigured for evolved data compression scheme signaling in accordancewith various aspects of the present disclosure.

FIG. 12 illustrates a block diagram of portions of a system including aUE configured for evolved data compression scheme signaling inaccordance with various aspects of the present disclosure.

FIG. 13 shows a block diagram of a wireless device configured forevolved data compression scheme signaling in accordance with variousaspects of the present disclosure.

FIG. 14 shows a block diagram of a wireless device configured forevolved data compression module configured for evolved data compressionscheme signaling in accordance with various aspects of the presentdisclosure.

FIG. 15 shows a block diagram of a base station evolved data compressionmodule configured for evolved data compression scheme signaling inaccordance with various aspects of the present disclosure.

FIG. 16 illustrates a block diagram of a system including a base stationconfigured for evolved data compression scheme signaling in accordancewith various aspects of the present disclosure.

FIG. 17 shows a block diagram of a device configured for use in wirelesscommunication for evolved data compression scheme signaling inaccordance with aspects of the present disclosure.

FIG. 18 shows a block diagram of a device configured for use in wirelesscommunication for evolved data compression scheme signaling inaccordance with aspects of the present disclosure.

FIG. 19 shows a block diagram of a wireless communication device forevolved data compression scheme signaling in accordance with variousaspects of the present disclosure.

FIG. 20 shows a block diagram of a base station for use in wirelesscommunication for evolved data compression scheme signaling inaccordance with various aspects of the present disclosure.

FIGS. 21-29 show flowcharts illustrating methods for evolved datacompression scheme signaling in accordance with various aspects of thepresent disclosure.

DETAILED DESCRIPTION

The described features generally relate to improved systems, methods, orapparatuses for evolved data compression scheme signaling. In somewireless communication schemes, such as in a high speed packet access(HSPA) system, data compression may be used to increase bandwidth. Datacompression may include header compression, payload compression, orboth. The compression of data may happen at various layers within acommunication system, including the packet data convergence protocollayer (PDCP). Additionally, the compression of data may be performed atbase stations as well as user equipments (UEs). In some instances, thecompression of packet headers and payloads may be based on previouslytransmitted packets. A wireless system which employs data compressionmay experience increased system capacity (e.g., by accommodating higherbandwidth and increased number of uses), faster data exchange (e.g.,quicker web page downloads), improved call setup (e.g., during cell edgescenarios for session initiation protocol (SIP) procedures), and UEtransmit power benefits.

In some examples, a wireless communication system may use an extendeddata compression header with fields to convey information about theheader, compression, packet, etc. In some cases the extended header mayinclude fields to convey the presence of a header extension (e.g., anExtension field), information regarding the data compression (e.g., anOption field), and information regarding the length of header fields(e.g., a Value field). Using these or other fields, the extended headermay convey various information to a base station or UE, such as datacompression context information (e.g., the Option field may indicatethat the data compression context was reset by the transmitter).

An extended header may be used in conjunction with a compressioncapabilities message sent between a transmitter and a receiver. Acompression capabilities message may be compressed or uncompressed. Insome cases, the message may convey information pertaining to thecompression rate supported by a device, or the compression contextprefill configuration. A compression configuration message may convey aPDCP control protocol data unit (PDU) for exchanging compression states(e.g., the message may convey PDCP SN and ciphering support, or indicatea new PDCP control PDU type). In some cases, a compression configurationmessage may include a PDCP control PDU for compression out of sync (OOS)or flow control (e.g., the message may indicate the maximum number ofbytes to compress, a 1-in-n packet compression ratio, or a reset requestto a particular context ID). A compression configuration message maysave compression context across a radio resource control (RRC)connection, enable or disable compression, and/or handle the PDCPdiscard timer.

For example, a base station and a UE may communicate informationregarding compression capabilities or configurations. The base stationmay transmit a message to the UE requesting indication of the UE toengage in extended capability communications (e.g., the base station maysend an extended UE capabilities request). In aspects, informationregarding compression capabilities or configurations may be included insuch extended capability communications. In one example, a base stationmay signal a UE to determine if the UE is compatible with a certaincompression configuration. The UE may respond to the request by sharingall the configurations which the UE supports and which are possible forcommunication with the base station. The UE may share this informationwith the base station via a message which includes uplink algorithminformation, downlink algorithm information, the compression ratesupported by the UE, the compressor context memory size, and/or theprefill configuration for the compressor context memory.

The base station may use the information conveyed by the message torequest the UE to use a particular configuration for compression. Thebase station may convey the request using a message that includes fieldsfor indicating the number of radio bearers (e.g., DRBs) which areconfigured, the resource block ID, the algorithm version and supportedcompression rate, the compressor context memory size, and/or the prefillconfiguration for the compressor context memory. The UE may acknowledgethe configuration request from the base station by sending a messagecarrying the confirmation for the request. Next, the UE may send amessage indicating to the base station whether the compression isenabled for PDCP PDUs following the indication (e.g., a modified PDCPcontrol PDU may carry the compression status indication). The messagemay include fields for data, control, PDU type, and/or a field whichaids in the re-transmission of control PDUs during handover. Thereceiver may receive the request from the transmitter and send anacknowledgment indicating that a particular context ID has been saved.

In some cases, a data compression scheme (e.g., an evolved datacompression scheme (eDCS) or uplink data compression (UDC)) may be usedin a wireless compression network to compress various portions of a datapacket, including headers, such as transmission control protocol(TCP)/Internet Protocol (IP) headers, session initiation protocol (SIP)data, portions of data payloads, or combinations of the same. By using adata compression scheme (e.g., eDCS or UDC) to compress all or portionsof data packets transferred in a wireless communication network,congestion in the network may be reduced. For example, using a datacompression scheme may allow for an increase in system capacity as itrelates to the number of devices using the wireless communicationnetwork. The use of a data compression scheme may accommodate higherbandwidth and an increase in the number of users of the wirelesscommunication network. Benefits may also include quicker downloads, suchas web page downloads. The use of a data compression scheme maypotentially improve call setup at the edges of cellular coverage usingSIP procedures. These benefits may result in more efficient power use bythe participating entities.

An eDCS functions by allowing both parties of a communication session(for example, a UE and a base station), to use a same compressioncontext. The compression context, and other compression-related options,may be communicated between the participating entities via a compressionheader, which may be applied to the beginning of a data packet. Thecompression header may include a compression scheme portion thatidentifies various compression options, such as the compression context.The compression scheme portion may also identify the portions of thedata packet to which the compression context is applied.

The following description of the figures provides examples, and is notlimiting of the scope, applicability, or examples set forth in theclaims. Changes may be made in the function and arrangement of elementsdiscussed without departing from the scope of the disclosure. Variousexamples may omit, substitute, or add various procedures or componentsas appropriate. For instance, the methods described may be performed inan order different from that described, and various steps may be added,omitted, or combined. Also, features described with respect to someexamples may be combined in other examples.

FIG. 1 illustrates an example of a wireless communications system 100 inaccordance with various aspects of the present disclosure. The system100 includes base stations 105, at least one UE 115, and a core network130. The core network 130 may provide user authentication, accessauthorization, tracking, internet protocol (IP) connectivity, and otheraccess, routing, or mobility functions. The base stations 105 interfacewith the core network 130 through backhaul links 132 (e.g., S1, etc.).The base stations 105 may perform radio configuration and scheduling forcommunication with the UEs 115, or may operate under the control of abase station controller (not shown). In various examples, the basestations 105 may communicate, either directly or indirectly (e.g.,through core network 130), with one another over backhaul links 134(e.g., X1, etc.), which may be wired or wireless communication links.

The base stations 105 may wirelessly communicate with the UEs 115 viaone or more base station antennas. Each of the base stations 105 mayprovide communication coverage for a respective geographic coverage area110. In some examples, base stations 105 may be referred to as a basetransceiver station, a radio base station, an access point, a radiotransceiver, a NodeB, eNodeB (eNB), Home NodeB, a Home eNodeB, or someother suitable terminology. The geographic coverage area 110 for a basestation 105 may be divided into sectors making up only a portion of thecoverage area (not shown). The wireless communications system 100 mayinclude base stations 105 of different types (e.g., macro or small cellbase stations). There may be overlapping geographic coverage areas 110for different technologies

In some examples, the wireless communications system 100 is a Long TermEvolution (LTE)/LTE-Advanced (LTE-A) network. In LTE/LTE-A networks, theterm evolved node B (eNB) may be generally used to describe the basestations 105, while the term UE may be generally used to describe theUEs 115. The wireless communications system 100 may be a heterogeneousLTE/LTE-A network in which different types of eNBs provide coverage forvarious geographical regions. For example, each eNB or base station 105may provide communication coverage for a macro cell, a small cell, orother types of cell. The term “cell” is a 3GPP term that can be used todescribe a base station, a carrier or component carrier associated witha base station, or a coverage area (e.g., sector, etc.) of a carrier orbase station, depending on context.

A macro cell generally covers a relatively large geographic area (e.g.,several kilometers in radius) and may allow unrestricted access by UEs115 with service subscriptions with the network provider. A small cellis a lower-powered base station, as compared with a macro cell, that mayoperate in the same or different (e.g., licensed, unlicensed, etc.)frequency bands as macro cells. Small cells may include pico cells,femto cells, and micro cells according to various examples. A pico cell,for example, may cover a small geographic area and may allowunrestricted access by UEs 115 with service subscriptions with thenetwork provider. A femto cell may also cover a small geographic area(e.g., a home) and may provide restricted access by UEs 115 having anassociation with the femto cell (e.g., UEs 115 in a closed subscribergroup (CSG), UEs 115 for users in the home, and the like). An eNB for amacro cell may be referred to as a macro eNB. An eNB for a small cellmay be referred to as a small cell eNB, a pico eNB, a femto eNB, or ahome eNB. An eNB may support one or multiple (e.g., two, three, four,and the like) cells (e.g., component carriers).

The wireless communications system 100 may support synchronous orasynchronous operation. For synchronous operation, the base stations 105may have similar frame timing, and transmissions from different basestations 105 may be approximately aligned in time. For asynchronousoperation, the base stations 105 may have different frame timing, andtransmissions from different base stations 105 may not be aligned intime. The techniques described herein may be used for either synchronousor asynchronous operations.

The communication networks that may accommodate some of the variousdisclosed examples may be packet-based networks that operate accordingto a layered protocol stack and data in the user plane may be based onthe IP. A radio link control (RLC) layer may perform packet segmentationand reassembly to communicate over logical channels. A medium accesscontrol (MAC) layer may perform priority handling and multiplexing oflogical channels into transport channels. The MAC layer may also usehybrid automatic repeat request (HARD) to provide retransmission at theMAC layer to improve link efficiency. In the control plane, the radioresource control (RRC) protocol layer may provide establishment,configuration, and maintenance of an RRC connection between a UE 115 andthe base stations 105. The RRC protocol layer may also be used for corenetwork 130 support of radio bearers for the user plane data. At thephysical (PHY) layer, the transport channels may be mapped to physicalchannels.

The UEs 115 may be dispersed throughout the wireless communicationssystem 100, and each UE 115 may be stationary or mobile. A UE 115 mayalso include or be referred to by those skilled in the art as a mobilestation, a subscriber station, a mobile unit, a subscriber unit, awireless unit, a remote unit, a mobile device, a wireless device, awireless communications device, a remote device, a mobile subscriberstation, an access terminal, a mobile terminal, a wireless terminal, aremote terminal, a handset, a user agent, a mobile client, a client, orsome other suitable terminology. A UE 115 may be a cellular phone, apersonal digital assistant (PDA), a wireless modem, a wirelesscommunication device, a handheld device, a tablet computer, a laptopcomputer, a cordless phone, a wireless local loop (WLL) station, or thelike. A UE may be able to communicate with various types of basestations and network equipment including macro eNBs, small cell eNBs,relay base stations, and the like.

The communication links 125 shown in wireless communications system 100may include uplink (UL) transmissions from a UE 115 to a base station105, or downlink (DL) transmissions, from a base station 105 to a UE115. The downlink transmissions may also be called forward linktransmissions while the uplink transmissions may also be called reverselink transmissions. Each communication link 125 may include one or morecarriers, where each carrier may be a signal made up of multiplesub-carriers (e.g., waveform signals of different frequencies) modulatedaccording to the various radio technologies described above. Eachmodulated signal may be sent on a different sub-carrier and may carrycontrol information (e.g., reference signals, control channels, etc.),overhead information, user data, etc. The communication links 125 maytransmit bidirectional communications using frequency division duplex(FDD) (e.g., using paired spectrum resources) or time division duplex(TDD) operation (e.g., using unpaired spectrum resources). Framestructures may be defined for FDD (e.g., frame structure type 1) and TDD(e.g., frame structure type 2).

In some embodiments of the system 100, base stations 105 or UEs 115 mayinclude multiple antennas for employing antenna diversity schemes toimprove communication quality and reliability between base stations 105and UEs 115. Additionally or alternatively, base stations 105 or UEs 115may employ multiple input multiple output (MIMO) techniques that maytake advantage of multi-path environments to transmit multiple spatiallayers carrying the same or different coded data.

Wireless communications system 100 may support operation on multiplecells or carriers, a feature which may be referred to as carrieraggregation (CA) or multi-carrier operation. A carrier may also bereferred to as a component carrier (CC), a layer, a channel, etc. Theterms “carrier,” “component carrier,” “cell,” and “channel” may be usedinterchangeably herein. A UE 115 may be configured with multipledownlink CCs and one or more uplink CCs for carrier aggregation. Carrieraggregation may be used with both FDD and TDD component carriers.

Wireless communications system 100 may include a packet data convergenceprotocol (PDCP) layer at a UE 115 and at a base station 105. The PDCPlayer may be responsible for header compression and decompression ofinternet protocol (IP) data flows using the robust header compression(ROHC) protocol, transfer of data (user plane or control plane),maintenance of PDCP sequence numbers SNs, and in-sequence delivery ofupper layer PDUs to lower layers. The PDCP layer may also manageelimination of duplicate packets, ciphering and deciphering of userplane data and control plane data, integrity protection and integrityverification of control plane data, and packet discard based on atimer-out timer. According to the present disclosure, the PDCP layer maybe responsible for data compression.

Wireless communications system 100 may also include an RLC layer thatconnects higher layers (e.g., RRC and PDCP) to the lower layers (e.g.,the MAC layer). An RLC entity in a base station 105 or a UE 115 mayensure that transmission packets are organized into appropriately sizedblocks (corresponding to the MAC layer transport block size). If anincoming data packet (e.g., a PDCP or RRC service data unit (SDU)) istoo big for transmission, the RLC layer may segment it into severalsmaller RLC protocol data unit (PDUs). If the incoming packets are toosmall, the RLC layer may concatenate several of them into a single,larger RLC PDU. Each RLC PDU may include a header including informationabout how to reassemble the data. The RLC layer may also ensure thatpackets are reliably transmitted. The transmitter may keep a buffer ofindexed RLC PDUs, and continue retransmission of each PDU until itreceives the corresponding acknowledgement (ACK). In some cases, thetransmitter may send a Poll Request to determine which PDU's have beenreceived and the receiver may respond with a Status Report. Unlike theMAC layer HARQ, RLC automatic repeat request (ARQ) may not include aforward error correction function.

An RLC entity may operate in one of three modes. In acknowledged mode(AM), unacknowledged mode (UM) and TM. In AM, the RLC entity may performsegmentation/concatenation and ARQ. This mode may be appropriate fordelay tolerant or error sensitive transmissions. In UM, the RLC entitymay perform segmentation/concatenation but not ARQ. This may beappropriate for delay sensitive or error tolerant traffic (e.g., voiceover Long Term evolution (VoLTE)). Transparent mode (TM) only performsdata buffering, and does not include either concatenation/segmentationor ARQ. TM may be used primarily for sending broadcast controlinformation (e.g., the master information block (MIB) and systeminformation block (SIBs)), paging messages, and RRC connection messages.Some transmissions may be sent without RLC (e.g, a random access channel(RACH) preamble and response).

Thus, in some examples, a wireless device such as a UE 115 may receive atransmission from another wireless device such as a base station 105requesting information about support for data compression. The UE 115may determine parameters related to the types of supported datacompression and communicate the information to the base station 105. Insome cases, the UE 115 may then receive a message from the base station105 that requests establishment of a data compression configuration. TheUE 115 may respond with confirmation or rejection of the proposedcompression configuration. If the configuration is confirmed, the UE 115and the base station 105 may exchange compressed data packets accordingto the configuration. The devices may also exchange status and controlinformation related to the compression configuration (e.g., in acompression header of a compressed message). A UE 115 communicating witha base station 105 is one implementation of the present disclosure, butother implementations are possible. For example, two UEs 115 maycommunicate with each other using the methods described herein.

The communications between the UEs 115 and the base stations 105 mayinclude the transmission of data packets. In an eDCS context, thetransferred data packets may include a compression header which mayindicate to the receiver how compression is to be applied to the datapacket. The compression header may, for example, indicate that portionsof the transmitted data packet are to be compressed, or the compressionheader may indicate that the entirety of the transmitted data packet isto be compressed. The compression header may not only indicate whichportions of the data packet are to be compressed, but which compressioncontext is to be applied to each portion. A compression context isapplied by a transmitter in order to compress a portion of a datapacket, and is also applied by a receiver in order to decompress theportion of the data packet. Thus, both the transmitters and receiversmay be described as being in sync or synchronized when both thetransmitters and receivers are applying the same compression context.Additional details are further explained below.

FIG. 2 illustrates an example of a wireless communications subsystem 200for evolved data compression scheme signaling in accordance with variousaspects of the present disclosure. Wireless communications subsystem 200may include UE 115-a, which may be an example of a UE 115 described withreference to FIG. 1. Wireless communications subsystem 200 may alsoinclude a base station 105-a, which may be an example of a base station105 described above with reference to FIG. 1. Base station 105-a maycommunicate with core network 130-a via backhaul link 132-a, such asdescribed with reference to FIG. 1. Additionally, base station 105-a maycommunicate with any UE 115 within its coverage area 110-a viacommunication link 120. Communication link 120-a may allow forbidirectional communication between a UE 115-a and a base station 105-aas generally described with respect to FIG. 1. For instance, a basestation 105 may transmit control and data information to a UE 115 usingtime and frequency resources.

Base station 105-a may receive one or more internet protocol (IP)packets 205 from core network 130-a. The IP packets may be packaged inservice data units (SDUs) and may convey data to a base station 105-a.At base station 105-a, the packet data convergence protocol (PDCP) layermay add headers to the one or more IP packets 205 to generate one ormore PDCP protocol data units (PDU) 210. PDCP PDU 210 may include aheader 215 followed by a payload 220. The header 215 may be an extendedheader, which may include information about the message format,transmitter, and/or communication scheme. In some cases, the PDCP layermay implement data compression for PDCP PDU 210 to increase the amountof data that may be sent using limited resources. The PDCP layer maycompress the header 215, the payload 220, or both. The compression mayreduce the resources used to convey the information of IP packet 205from base station 105-a to UE 115-a (e.g., the size of PDCP PDU 210 maybe smaller than the size of the corresponding IP packet 205 even if theyconvey the same data). This may be accomplished by including referencesin PDCP PDU 210 to one or more matching bit sequences in previouspackets rather than including the bit sequences themselves.

At base station 105-a, the IP packet 205 may be processed by additionallayers after PDCP compression. For example, the radio link control (RLC)layer may receive the compressed PDCP PDUs 210 from the PDCP layer,segment the PDCP PDUs 210, add headers, and submit the RLC packets tothe medium access control (MAC) layer. The MAC layer may attach bitpadding and additional header information to the packet beforetransmitting the data over the physical layer (e.g., using waveforms inthe time and frequency domains). In some cases one wireless device(e.g., base station 105) in communication with another wireless device(e.g., UE 115-a) may retain context related to a compression capabilityand/or configuration. The information may be used by the retainingdevice to facilitate future communications.

Prior to initiating transmissions using a data compression scheme, basestation 105-a may communicate with UE 115-a to determine if UE 115-asupports extended data compression capabilities. Furthermore, basestation 105-a may communicate with UE 115-a to determine whichcompression configurations UE 115-a supports. Thus, base station 105-amay use a compression configuration to communicate with UE 115-a basedon compression capability information obtained from UE 115-a. After acompression configuration is established, the devices may exchangestatus and/or control information using fields in an extendedcompression header of the exchanged packets, or using dedicated statusand/or control messages.

In some cases one wireless device (e.g., base station 105-a) incommunication with another wireless device (e.g., UE 115-a) may retain acompression context related to a compression capability orconfiguration. The information may be used by the retaining device tofacilitate future communications.

FIG. 3A illustrates an example of an extended compression header 301 inaccordance with various aspects of the present disclosure. In somecases, the extended compression header 301 may be used for transmissionsbetween a UE 115 and a base station 105, which may be examples of a UE115 and a base station 105 described with reference to FIG. 1. In othercases, the extended compression may be used for communications betweenother wireless devices (e.g., between two UEs 115). The extendedcompression header 301 may itself be compressed or un-compressed, andmay precede a payload that is either compressed or uncompressed. Theextended compression header 301 may include fields for conveyinginformation regarding compression scheme, context ID, and/or thepresence or absence of additional header extension fields. Although thefields of extended compression header 301 are shown in a particularorder, the fields may be arranged in alternate configurations.Additionally, some of the fields may be absent (e.g., only a portion ofthe fields may be included in a header extension).

The extended compression header 301 may be transmitted from one wirelessdevice to another and may be used to convey data, as well as controlinformation which the receiving wireless device may use to configureitself to facilitate proper reception of communications from thetransmitting device. The control information may be carried in fields(e.g., in the extended header 305) and may be any length. For example,the extended compression header 301 may include a packet type (Pkt Type)field 310-a which may indicate whether or not compression has beenenabled. Packet type field 310-a may be followed by a cyclic redundancycheck (CRC) field 315-a, which may be used to detect errors in theextended compression header 301. Additionally, extended compressionheader 301 may include an extension field 320-a, which may indicate theabsence or presence of the header extension 305.

The extended compression header 301 may include an option field 325-a,which may be used to convey information about context ID and variouscompression factors. For example, the option field 325-a may indicate toa receiver that the transmitter has reset the data compression contextfor that receiver. Additionally, the option field 325-a may convey arequest to a receiver to check-point a data compression context. In somecases, the option field 325-a may indicate that the receiver should“freeze” to a given context ID for the next “n” number of packets (e.g.,the receiver should continue to use the same context ID for the “n”packets following extended compression header 301). The option field325-a may be used to indicate when compression is disabled for a numberof bits following the field. In some instance, the option field 325-amay be used to support compressed payloads using multiple context IDs(e.g., the option field 325-a may indicate whether a particular contextID should be used by the receiver for the entirety of the payload, orjust a portion). Additionally, the option field 325-a may supportcompression for payloads without compression meta data (e.g., the optionfield 325-a may indicate that meta data is absent from the packet).

The extended compression header 301 may include a value field 330-a,which may convey context ID and/or the number of packets to which theoption field 325-a applies. For example, if the value field 330-acarries a value of 8, and the option field 325-a indicates that acontext “freeze” should be enabled for the next “n” packets, thereceiving entity may use the same context for the next 8 packets, asindicated by the value field 330-a. The extended compression header 301may also include an additional extension field 335-a and a match field340-a. Extended compression header 301 may include a distance to pointerfield (Dist to Ptr) 345-a, an LB length field 350-a, and/or a lengthfield 355-a. Extended compression header 301 may further include a datafield 360-a, which may convey additional meta data (e.g., data whichdescribes other data in the extended compression header 301) to thereceiver.

Extended compression header 301 may be used in conjunction with acompression capabilities message which is sent between a transmitter anda receiver (e.g., between a UE 115 and a base station 105). Acompression capabilities message may be compressed or uncompressed. Insome cases, a compression capabilities message may convey informationpertaining to the compression rate supported by the transmitting device,or the compression context prefill configuration. Additionally, acompression configuration message may convey PDCP control PDU forexchanging compression states (e.g., the message may convey PDCPsequence number (SN), ciphering support, and/or indicate a new PDCPcontrol PDU type). In some cases, a compression configuration messagemay include PDCP control PDU for compression out of sync/flow control(e.g., the message may indicate the maximum number of bytes to compress,1-in-n packet compression, and/or reset the compressor to a particularcontext ID). A compression configuration message may also savecompression context across a radio resource control (RRC) connection,enable compression, disable compression, and/or handle a PDCP discardtimer.

In some cases, the compression configuration message may indicatewhether a UE supports buffer transfer for PDCP re-establishment (e.g.,handover and RRC re-establishment upon radio link failure (RLF)). In thecase where it is indicated that the UE supports buffer transfer,following PDCP re-establishment the UE may retain the previouslytransmitted buffer context and compressed PDUs. If the indication isabsent, the UE may not support buffer transfer across re-establishmentof PDCP. In such cases, the base station may reset the UDC context anddiscard the received compressed packets according to a previous context.In some cases, buffer transfer may refer to the transfer of acompression buffer from a source base station to target base stationduring handover/re-establishment. In some examples, an indication mayprovide the maximum number of data bearers for which compression issupported.

A compression configuration message may also indicate a header lengthand diagnostic parameters. For example, a header length to be compressed(e.g., in multiples of 20 bytes) may be indicated when header-onlycompression may be used. In some cases, checksum source bytes may beindicated, such as the bit string of bytes from uplink compressionmemory on which a checksum was computed. For example, when a checksum iscomputed and fails to match the checksum in a header, the correspondingsource bytes from the uplink compression memory that were used tocompute the checksum may be sent to the UE along with a resetindication. Additionally or alternatively, a PDCP sequence number may beindicated, such as a PDCP sequence number that failed a checksum causeda reset. For example, when a header checksum is computed and fails tomatch the checksum in the header, the corresponding PDCP sequence numbermay be sent to the UE along with the reset indication.

In some cases, compressed packets may rely on the uplink compressionmemory for decompression and therefore uplink compression memory at atransmitter and/or a receiver should be synchronized in order toproperly compress/decompress packets. Cyclical redundancy check (CRC)field in packet header may be used to detect errors (e.g.,synchronization errors) in the packet transmission by a validationprocess at the receiver. If any errors are detected in the transmissionof the packet, uplink compression memory at the transmitter and/or thereceiver may be reset to be synchronized. Therefore, a transmitter mayneed to indicate to the receiver to reset the uplink compression memorybefore processing a packet. In an example, the packet type field 310-amay indicate various decompression options (e.g., whether to reset theuplink compression memory) to a receiver to process a packet. The packettype field 310-a may include a plurality of bits (e.g., 3 bits) toindicate various decompression options to a receiver.

In another example, compression/decompression operations may be a largeload on the central processing unit (CPU). In order to reduce a load ofthe CPU, one or more steps (e.g., adding a packet to the uplinkcompression memory) of compression/decompression operations may beskipped. Also to reduce a load of the CPU, one or more steps ofcompression/decompression operations may be selectively performed. Forexample, uplink compression memory may be selectively updated.Therefore, a transmitter may need to indicate to the receiver one ormore steps of compression/decompression operations to be selectivelyperformed.

For example, the packet type field 310-a may indicate a full packetcompression/decompression option. The full packetcompression/decompression option may include adding an entire packet toa memory (e.g., uplink compression memory) and performing adecompression of the packet as indicated by a number of matches andpointer metadata fields. In another example, the packet type field 310-amay indicate a header compression/decompression option. For example, theheader compression/decompression option may include adding a header of apacket to a memory (e.g., uplink compression memory) and performing adecompression of the header as indicated by a number of matches andpointer metadata fields. The packet type field 310-a may indicate acompression attempted but no matches found compression/decompressionoption. For example, the compression attempted but no matches foundcompression/decompression option may include adding an entire packet toa memory (e.g., uplink compression memory), however, the number ofmatches and pointer of metadata fields may not be included in thecompressed packet.

The packet type field 310-a may indicate a no compressioncompression/decompression option. For example, the no compressioncompression/decompression option may include not adding a packet to amemory (e.g., uplink compression memory) and the number of matches andpointer of metadata fields may not be present in the compressed packet.The packet type field 310 may indicate a compression performed but nomemory update compression/decompression option. For example, thecompression performed but no memory update compression/decompressionoption may include not adding a packet to a memory (e.g., uplinkcompression memory) and performing a decompression as indicated by anumber of matches and pointer metadata fields. The packet type field310-a may indicate a reset compression/decompression option. Forexample, the reset compression/decompression option may includeresetting a memory (e.g., resetting uplink compression memory to allzeros), adding an entire packet to the memory (e.g., uplink compressionmemory) and number of matches and pointer metadata fields may not bepresent in the compressed packet.

If a header extension 305 is included, the extended compression header301 may also include an option field 325-a. A corresponding value field330-a may include values corresponding to the options included in theoption field 325-a. The option field 325-a may be used to conveyinformation relating to various compression-related options. Theconveyed information may relate to specific actions that the receiver ofthe extended compression header 301 may take, or may provide detailsregarding how compression is to be or has been applied to a data packet.A number of different options may be conveyed.

For example, the option field 325-a may be used to convey a compressionoption that may reset a compression context. For example, thetransmitter may use the option field 325-a to convey to a receiver acompression option of resetting a compression context. Thus, a receiverwill know that it should also reset its compression context to match thecompression context used by the transmitter. In this example, the valuefield 330-a may include the compression context identification (ID)which corresponds to the desired compression context. This example maybe beneficial when the receiver and the transmitter are out of sync witheach other. For example, insufficient bandwidth or slow datacommunication rates could result in a receiver lagging behind thetransmitter and even dropping data packets in order to catch up. In thisexample, it is possible that the receiver and the transmitter may becomeout of sync, such that the receiver begins to apply an incorrectcompression context to received data packets. This may result insignificant decompression failure rates. Therefore, the receiver mayrequest that the transmitter reset its compression context, through, forexample, a compression control request. When the transmitter resets itscompression context, the transmitter may use the option field 325-a andthe value field 330-a to convey to the receiver the reset compressioncontext. Similarly, resetting a compression context may be useful when atransmitter, for example, is in a handover situation, where the receivermay be changed.

The option field 325-a may be used to convey a compression option thatmay disable the compression header for a number of data packets. Forexample, the option field 325-a may be used to indicate that thecompression header will be disabled for the next “n” data packets, where“n” is an integer number greater than zero. Thus, in order to avoidentering an out of sync situation that might arise because of bandwidthcongestion, a receiver may inform a transmitter to temporarily stoptransmitting the compression header with the next “n” data packets. Inthis example, the transmitter and the receiver may continue applying anexisting compression scheme until the “n” data packets have beentransmitted, at which time the transmitter will resume transmission ofthe compression header with the corresponding data packets. In thisexample, the value field 330-a may include the value of “n.”

The option field 325-a may be used to convey a compression option thatmay request an entity of the communication to check a compressioncontext. For example, the option field 325-a may be used by atransmitter to request that a receiver store a compression context. Whenboth the receiver and the transmitter store a same compression context,the receiver and the transmitter and enabled to reuse that compressioncontext in the future. Thus, if the communication between a receiver anda transmitter is paused, the communication may resume with each entity(e.g., the transmitter or receiver) using the stored compressioncontext, meaning that the entities need not revert to an out-of-datecompression context. Similarly, when the transmitter and the receiverreset their compression contexts, the transmitter and the receiver mayreset to the stored compression context. Storage of a compressioncontext may occur as frequently as a check point option is received inthe option field 325-a. When a check point option is received in theoption field 325, the value field 330-a may include a compressioncontext ID corresponding to the desired compression context to bestored.

The option field 325-a may be used to convey a compression context for anumber of data packets. For example, the option field 325-a may be usedto request using a compression context for the next “n” data packets.Thus, the receiver and transmitter may understand that the next “n” datapackets will maintain the same compression context without change. Thevalue field 330-a may indicate the value of “n.” The compression optionmay be especially beneficial when used for SIP template compression andduring Wi-Fi use.

The option field 325-a may be used to convey a compression option thatmay indicate that a compression context is to be used for one or moreportions of a data packet. For example, the option field 325-a may beused to indicate that piecewise compression is an option, and thecorresponding value field 330-a may indicate a compression context ID tobe applied to a specific portion of the data packet. The value field330-a may also include a length value to indicate the specific portionof the data packet to which the compression context ID is to be applied.This may be particularly useful when different compression contexts aredesired to be applied to different portions of a data packet. Forexample, a first compression context may be applied to a TCP/IP headerwhile a second compression context may be applied to an SIP data. Theapplied compression context and the part of the data packet to which itis applied may be defined in the value field 330-a.

Alternatively, the option field 325-a may be used to convey acompression option that may indicate that a compression context is to beused for an end or remaining portion of a data packet. For example, theoption field 325-a may be used to indicate that a compression context isto be applied to the last half or last portion of a data packet. Thisexample may apply when an entire data packet is to be compressed using asame compression context, or when a first compression context has beenapplied to a first portion of the data packet and the remainder of thedata packet is to be compressed using a second compression context. Inthis example, the value field 330-a may include the desired compressioncontext ID, but need not include a length indicator.

In an additional example, the option field 325-a may be used to convey acompression option that may disable the inclusion of compression headermetadata in the extended compression header 301. For example, the optionfield 325-a may be used to indicate that no compression header metadatais to be transmitted. As described below, additional fields in theextended compression header 301 may include compression header metadata.However, it may not be necessary to convey all of the compression headermetadata with each extended compression header 301. Thus, in thisexample, the option field 325-a may indicate that compression headermetadata is not included in the extended compression header 301. Thecorresponding value field 330-a may include the compression context IDto be applied, even in the absence of compression header metadata.

The extended compression header 301 may include more than one optionfield 325-a and value field 330-a. Thus, and for example, if acompression context is to be applied to a first portion of the datapacket, and a different compression context is to be applied to a secondportion of the data packet, the extended compression header 301 mayinclude two option fields 325-a and two corresponding value fields330-a. Each option field 325-a and value field 330-a combination ismarked by an extension field, such as extension field 320-a. Thus, theextended compression header 301 may include one or more additionalextension fields 335-a.

A match field 340-a, a distance to pointer field 345-a, an look back(LB) length field 350-a and a length field 355-a may also be includedafter the one or more extension fields. Of these, the distance topointer field 345-a, the LB length field 350-a and the length field355-a may include compression header metadata. As explained above, thecompression header metadata may be excluded from some extendedcompression headers 301, as determined by the option field 325-a of theheader extension 305.

The extended compression header 301 may include additional headers, asindicated by the additional header field 360-a, and may also be followedby additional metadata 365-a. The extended compression header 301 isjust one example of an extended compression header that may be used toconvey compression-related options to a receiver. Other examples mayalso be used.

FIG. 3B illustrates another example of an extended compression header302 in accordance with various aspects of the present disclosure. Insome cases, the extended compression header 302 may be used fortransmissions between a UE 115 and a base station 105, which may beexamples of a UE 115 and a base station 105 described with reference toFIG. 1. In other cases, the extended compression may be used forcommunications between other wireless devices (e.g., between two UEs115). The extended compression header 302 may itself be compressed orun-compressed, and may precede a payload that is either compressed oruncompressed. The extended compression header 302 may include fields forconveying information regarding compression scheme, context ID, and/orthe presence or absence of additional header extension fields asdescribed in relation to FIG. 3A. Additionally, the extended compressionheader 302 may include fields for conveying information pertaining topayload length and/or compression.

For example, the extended compression header 302 may include a lengthindicator (Len. Ind) field 370. The length indicator field 370 may beused by the transmitting entity to indicate whether a compressioncontext should be applied to only a specific portion of a data packet orto the remainder of the data packet or to convey the length of a payload(e.g., the length indicator field 370 may indicate the length for thepayload following the header). The extended compression header 302 mayalso include a length field 375, which may indicate a length of thespecific portion of the data packet which has been compressed using aparticular context ID (e.g., the context ID conveyed by the value field330-b. A base station 105 or UE 115 may send a message using eitherextended compression header 301, extended compression header 302, or anextended compression header which includes any arrangement of the fieldsincluded in extended compression headers 301 and/or 302.

In some cases, an initial packet may be transmitted using a differentheader configuration than subsequent packets. For example, subsequentpackets may exclude the Option field 325-b, the length indicator field370, the length field 375, the Value field 330-b, and/or the additionalextension field 335-b. Subsequent packets with a reduced header may alsobe used with extended compression header 301. The header values ofextended compression header 301 or 302 may be used in conjunction with asession initiation protocol (SIP) and with encryption methods. In somecases only the dynamic parts of extended compression header 301 or 302(e.g., the field values) are compressed. In other cases, both the staticand the dynamic parts of extended compression header 301 or 302 arecompressed. In yet other cases, only the static parts may be compressed.

In some cases, the extended compression header 302 may include adifferent header extension 307, as indicated by the extension field320-b. The extended compression header 302 may include an option field325-b, a corresponding value field 330-b, a length indicator field 370,and a length field 375. The option field 325-b and the value field 330-bof the header extension 307 may be used in essentially the same way asthe option field 325-a and the value field 330-a of the header extension305. However, where the header extension 305 may have included lengthinformation in its value field 330-a, the header extension 307 mayinstead include length information in a separate length field 375.

For example, the length indicator field 370 may indicate whether acompression context ID included in the value field 330-a should beapplied to the remainder of the data packet's payload or to just aportion of the payload. If the length indicator field 370 indicates thata compression context ID should be applied to only a portion of the datapacket, then the length field 375 may indicate the length of the portionto which the compression context ID should be applied.

As with the extended compression header 301, the extended compressionheader 302 may include an additional extension field 335-b to indicatethat additional header extensions 307 may be included in the extendedcompression header 302.

FIG. 4 illustrates an example of a process flow 400 for evolved datacompression scheme signaling in accordance with various aspects of thepresent disclosure. Process flow 400 may be used by a UE 115-b and abase station 105-b, which may be examples of a UE 115 and a base station105 described with reference to FIG. 1. Process flow 400 may also beused by wireless devices other than those depicted in FIG. 4. Processflow 400 may use messages with extended compression headers such asdescribed with reference to FIGS. 3A and/or 3B. Prior to initiatingtransmissions based on the data compression scheme, base station 105-bmay communicate with UE 115-b to determine if UE 115-b supports extendeddata compression capabilities. For example, base station 105-b may senda message via a signaling radio bearer (e.g., attached to an RRCsecurity mode PDU) to determine whether UE 115-b is capable ofsupporting an extended signaling (e.g., an extended data compression)radio bearer (e.g., a Q2X bearer). Using the established radio bearer,base station 105-b may communicate with UE 115-b to determine whichcompression configurations may be supported. Base station 105-b may usecompression information from UE 115-b to select a compressionconfiguration. Finally, base station 105-b may request UE 115-b to usesaid selected compression configuration.

At step 405, UE 115-b may receive a compression capability request frombase station 105-b related to a capability for compressing a payload ofa wireless data transmission. In some cases, base station 105-b maytransmit a message to UE 115-b requesting an indication of the abilityof UE 115-b to engage in extended capability communications (e.g., basestation 105-b may send an extended UE capabilities request).Additionally, the compression capability request may direct UE 115-b toindicate which compression configurations UE 115-b supports. Forexample, base station 105-b may signal UE 115-b to determine whether UE115-a is compatible with a certain compression configuration.

At step 410, UE 115-b may identify at least one compression capabilityparameter based on the compression capability request. In some examplesthe capability parameter relates to a compression rate support parameteror a compression context prefill configuration.

At step 415, UE 115-b may transmit a compression capability response tobase station 105-b based at least in part on the compression capabilityrequest and the at least one compression capability parameter. Forexample, UE 115-b may respond to the request by sharing the supportedconfigurations of UE 115-b. UE 115-b may share this information withbase station 105-b via a message which includes uplink and/or downlinkalgorithm information, the compression rate supported by UE 115-a, thecompressor context memory size, and/or the prefill configuration for thecompressor context memory. In some cases, UE 115-b may receive acompression capability response based at least in part on a compressioncapability request sent by UE 115-b. UE 115-b or base station 105-b mayselect a compression configuration based at least in part on thecompression capability response.

At step 420, UE 115-b may receive a compression configuration requestfrom base station 105-b. For example, base station 105-b may signal UE115-b requesting UE 115-b use a selected compression configuration. Inother words, base station 105-b may request UE 115-b to use a particularconfiguration for compression. Base station 105-b may convey the requestusing a message that may include fields for indicating the number ofdata radio bearers (DRBs) which are configured, the radio bearer ID(s),an algorithm version, a supported compression rate, the compressorcontext memory size, and/or the prefill configuration for the compressorcontext memory. In some examples, UE 115-b may transmit a compressionconfiguration request to base station 105-b.

At step 425, UE 115-b may transmit a compression configurationconfirmation (or rejection) based at least in part on the compressionconfiguration request. In some examples, UE 115-b may append theconfirmation/rejection message at the end of a packet. In some cases, UE115-b may transmit a compression configuration rejection based at leastin part on the nature of the compression configuration request (e.g., UE115-b may not support the requested compression configuration).

At step 430, UE 115-b or base station 105-b may transmit a compressionstatus indication. In some examples, the compression status indicationmay include a ciphered PDCP control PDU type, an unciphered PDCP controlPDU type, a sequence number, and/or a compression enable/disableindication. For example, UE 115-b may send a message indicating to basestation 105-b whether compression is enabled for the PDCP PDUs followingthe indication (e.g., a modified PDCP control PDU may carry thecompression status indication). The message may include fields for data,control, PDU type, and/or as a field which aids in the re-transmissionof control PDUs during handover.

As described above, the compression status indication may include acompression enable/disable indication. In some examples, then, a PDCPcontrol PDU may be used to indicate whether compression is enabled ordisabled for data PDUs that may follow the transmission of thecompression status indication.

For example, base station 105-b may establish a radio bearer with nocompression but may later enable compression on that radio bearer. Inthis instance, a PDCP control PDU indicating that compression is enabledmay be transmitted before the first compressed data PDU is transmitted.

In another example, base station 105-b may establish a radio bearer withcompression but may later disable compression on that radio bearer. Inthis instance, a PDCP control PDU indicating that compression isdisabled may be transmitted after the last compressed data PDU istransmitted.

In yet another example, base station 105-b may establish a radio bearerwith compression but UE 115-b may later disable compression on thatradio bearer. In this instance, a PDCP control PDU indicating thatcompression is disabled may be transmitted after the last compresseddata PDU is transmitted.

In another example, base station 105-b may establish a radio bearer withcompression but UE 115-b may later disable compression on that radiobearer, as described above. However, if UE 115-b then desires tore-enable compression on that bearer, a PDCP control PDU indicating thatcompression is enabled may be transmitted before the first compresseddata PDU is transmitted.

In aspects, the compression status indication may include a PDCP controlPDU type that itself may include an enable/disable indication. When basestation 105-b establishes a radio bearer with compression in a sameconfiguration message, a PDCP control PDU indicating that compressionhas been enabled may or may not actually be transmitted. As the radiobearer was established via a same configuration message, a compressionstatus indication may not be needed. Whether the compression statusindication is transmitted may be determined by a predeterminedimplementation, for example.

At step 435, UE 115-b or base station 105-b may transmit a compressioncontrol message (e.g., request). In some examples transmitting thecompression control message comprises transmitting the compressioncontrol message on a high priority radio bearer (e.g., a radio bearerhaving higher priority than another radio bearer). For example, if UE115-b is compatible, base station 105-b may set up a new DRB. In someexamples the compression control message is based at least in part on adetermination that an amount of available wireless device processingresources is below a threshold. In some examples the compression controlmessage is based on a determination that the wireless device has failedto decompress or decode a number of packets. In some examples thecompression control message comprises at least one of a compressionstate indication, a compression scope (e.g., compress header, payload,or both header and payload) indication, a data compression threshold, acompression enable/disable indication, a compressed packet ratio, or acontext ID reset request.

At step 440, UE 115-b and base station 105-b may exchange compressedpackets based at least in part on the established compressionconfiguration The compressed packets may include one or more extendedcompression header fields indicating at least one of a compressioncontext reset request, a compression disable request associated with anumber of subsequent packets, a compression context synchronizationindication, a compression context freeze request, a multi-partcompression indicator associated with a plurality of compressioncontexts, or a compression metadata indicator. UE 115-b and base station105-b may store compressed and uncompressed versions of transmittedpackets. In such instances, UE 115-b may reset a context ID based on theuncompressed version of the packet.

In some examples, UE 115-b or base station 105-b may transmit a contextidentification (ID) save confirmation request. The devices may transmita compression enable request or a compression disable request based atleast in part on processing limitation, a traffic type, or adetermination that a resource grant volume is sufficient to clear anuncompressed memory buffer during one or more periodic intervals. Insome examples the compression capability parameter comprises acompression rate support parameter or a compression context prefillconfiguration.

In some cases, a receiver such as UE 115-b or base station 105-b mayneed to handle out of sync communications. For example, the receiver mayfail to decompress received packets (e.g., data compression CRC failure)or may detect invalid PDU contents after decompression. In such cases,the receiver may trigger a reset for the sender via a “reset compressor”field in the compression control message with a desired compressioncontext ID. Additionally or alternatively the receiver may declare aradio link failure (RLF) and establish a fresh data connection. In termsof flow control, if the receiver is running out of memory duringdecompression, the receiver may request the transmitter to stopcompression and/or reduce the number of compressed bytes (e.g., thereceiver may use a compression control message field). In suchinstances, the flow control messages may be sent out-of-band so thatthey are prioritized over regular DRB messages.

In some cases, the same compressor context may be maintained across RRCconnections, which may improve efficiency. During an active data call, abase station and UE may periodically request, via an extendedcompression PDU header, the peer to back-up the existing compressioncontext. The compression PDU header CRC may serve as one of the uniqueidentifies for the context ID. For a new RRC connection, a base stationmay send the context ID as part of the compression configurationrequest. If UE 115-b has the same context ID backed-up, the UE 115-b mayaccept that configuration. If UE 115-b does not have the same context IDbacked-up, the UE 115-b may reject the base station configuration, whichmay trigger the base station to start a fresh extended capabilityrequest procedure.

UE 115-b may dynamically enable/disable data compression based onvarious parameters such as available UL resources, grant assignment, ULthroughput, grant size and/or grant frequency. For example, is UE 115-bis getting grants often enough to clear its uncompressed buffers, the UEmay disable data compression. In some cases, UE 115-b may select acertain percentage of packets to be compressed. Additionally oralternatively, UE 115-b may base compression decisions on traffic type.For example, UE 115-b may choose a compression mode based on IP flowheader information (e.g., UE 115-b may base the compression on a perflow basis using packet header information), flow rate, and/or trafficcontent.

In some cases, a wireless system may use a PDCP discard timer whichindicates to a device when a packet should be dropped (e.g., upon expiryof the timer). Dropping a packet may cause a loss of synchronizationbetween a transmitter and receiver, retransmission of packets, andcompression reset. Thus, a UE may disable the PDCP timer for allcompressed (e.g., and corresponding uncompressed) PDCP SDUs. In such aninstance, the size of the compressed PDCP PDU buffer may be controlledbased on the rate at which the discard timer expires. The PDCP PDU maybe retransmitted until the packet is delivered or RLF is declared. In analternative method, the UE may perform compression on the fly (e.g., atthe time of transmission). In aspects, in this manner compressed datamay not be stored. Thus, the UE may keep the compressor context bufferup-to-date without any compressor context resets. In another example,the UE may maintain 2 queues (e.g., in software (SW)); one forcompressed packets and one for un-compressed packets. The UE may resetthe compressor when the packets are dropped due to the PDCP discardtimer and identify and exchange the last successful compressor contextID. For example, if the “nth” packet is dropped from a compressed queue,then all the compressed packets from the (n+1)th packet in thecompressed queue may be dropped and replaced by compressing the (n+1)thand beyond packets from the un-compressed queue using the new compressorcontext.

Thus, in some examples UE 115-b or base station 105-b may disable a PDCPdiscard timer based at least in part on the compression capabilityrequest. The devices may receive a compressed packet, wherein thecompressed packet is compressed immediately prior to transmission. Thedevices may reset a compression queue based on an indication that acompressed packet has been dropped. In some cases, the transmittingdevice may compress a packet based on the determination that the packetis scheduled for immediate transmission (e.g., to avoid complicationsdue to the PDCP discard timer).

FIG. 5 illustrates an example of a process flow 500 for evolved datacompression scheme signaling in accordance with various aspects of thepresent disclosure. The process flow 500 may be between a base station105-c and a UE 115-c, for example. The base station 105-c may be anexample of the base station 105 of FIG. 1, while the UE 115-c may be anexample of the UE 115 of FIG. 1. While the process flow 500 illustratescommunication between a base station 105-c and a UE 115-c, thecommunications shown need not be limited to the illustrated combination.For example, similar communication flows may exist between two differentUEs 115-c, or two different base stations 105-c. Additionally, while thecommunication flow 400 illustrates a transmission from the UE 115-c tothe base station 105-c, the roles may be reversed.

In process flow 500, the UE 115-c first identifies a compression optionthat is to be applied (at block 510). The compression option mayinstruct a receiver to reset its compression context, for example. Or,the compression option may include disabling the transmission of theextended compression header for a specified number of data packets. Thecompression option may be to request that a receiver check point acompression context. Or, the compression option may be to request that acompression context be frozen and used for a specific number of datapackets. The compression option may indicate that a compression contextis to be applied to a portion of a data packet, or even to the remainingportion of a data packet. Additionally, the compression option mayindicate that an extended compression header will include no compressionheader metadata.

Once the UE 115-c identifies a compression option, the UE 115-c maygenerate an extended compression header in which to include theidentified compression option (at block 510). As the UE 115-c mayidentify more than one compression option, the UE 115-c may includemultiple compression options in a single extended compression header(in, for example, different header extensions). Once the extendedcompression header has been generated, the UE 115-c may append theextended compression header to a data packet and transmit the combinedextended compression header and data packet to the base station 105-c.The base station 105-c then receives the combined extended compressionheader and data packet and applies the compression options included inthe extended compression header.

As explained above, while the example illustrated in FIG. 5 is specificto a transmission from a UE 115-c to a base station 105-c, the conceptsillustrated may be applied to any wireless communication between atransmitter and a receiver.

FIG. 6A, FIG. 6B, and FIG. 6C show examples of a compression header, inaccordance with aspects of the present disclosure. In particular, FIG.6A shows an example of a compression header, in accordance with aspectsof the present disclosure. In particular, FIG. 6A illustrates acompression header framework 601 that includes an extended compressionheader 604. For simplicity, only a portion of the extended compressionheader 604 is illustrated in FIG. 6A. The extended compression header504 may be an example of either of the extended compression headers 300,302 of FIGS. 3A and 3B.

The extended compression header 605 may be used between a transmitterand a receiver when a compression context ID and a portion of the datapacket to which the compression context ID is to be applied have beenpre-negotiated. In other words, in the example shown in FIG. 6A, boththe receiver and the transmitter already know what type of compressionto be applied and to what portion of the data packet the compressionscheme is to be applied. Thus, there is no need to convey thecompression context or other compression-related values in the extendedcompression header 504.

Therefore, the extended compression header 604 includes a packet actionfield 609 which has a corresponding value 610 indicating thatcompression is enabled for the data packet. The extended compressionheader 604 also includes a CRC field 615 which includes a correspondingCRC value 616. Following the CRC field 615, the extended compressionheader 604 includes an extension field 621. Because no compressionoptions need be conveyed in the extended compression header 604 (as aresult of the options being pre-negotiated), the value 622 for theextension field 621 indicates that the extension header is absent.

FIG. 6B illustrates a compression header framework 602 that includes anextended compression header 605 to be used on a first data packet, andan extended compression header 606 to be used on subsequentlytransmitted data packets. For simplicity, only a portion of the extendedcompression headers 605, 606 are illustrated in FIG. 6B. The extendedcompression headers 605, 606 may be examples of the extended compressionheader 300 of FIG. 3B.

The extended compression header 605 may be used between a transmitterand a receiver when a compression context ID and a portion of the datapacket to which the compression context ID is to be applied have notbeen pre-negotiated. In other words, in the example shown in FIG. 6B,the transmitter may convey to the receiver various identifiedcompression options that the receiver may apply to one or more portionsof the transmitted data packet.

Therefore, the extended compression header 605 includes a packet actionfield 611 which has a corresponding value 612 indicating thatcompression is enabled for the data packet. The extended compressionheader 605 also includes a CRC field 617 which includes a correspondingCRC value 618. Following the CRC field 617, the extended compressionheader 605 includes an extension field 623. Because the transmitter hasneed to convey compression options to the receiver in the extendedcompression header 605, the extension field 623 has a value 624 thatindicates that an extension header is present (in the form of optionfield 627 and value field 630). In this example, the option field 627indicates (in its value 628) that a portion of the data packet (portion1) is to be compressed using the value 631 in value field 630. The value631 indicates the compression context ID to be applied to a length ofthe data packet. In this example, no additional compression options needto be conveyed to the receiver, and so the extended compression header605 includes a second extension field 635 which indicates in itscorresponding value 636 that additional extension headers are absent.

Assuming the transmitter and the receiver intend to use the samecompression scheme for successive data packets, future data packets mayinclude a simplified versions of the extended compression header 606.Extended compression header 606 includes a packet action field 613 witha value 614 which indicates that compression is enabled for the datapacket. Extended compression header 606 also includes a CRC field 619with a CRC value 620. And, because these successive data packets neednot convey additional compression options, the extended compressionheader 606 includes an extension field 625 having a value 626 indicatingthat the extension header is absent.

FIG. 6C illustrates a compression header framework 603 that includes anextended compression header 607 to be used on a first data packet, andan extended compression header 608 to be used on subsequentlytransmitted data packets. For simplicity, only a portion of the extendedcompression headers 607, 608 are illustrated in FIG. 6C. The extendedcompression headers 607, 608 may be examples of the extended compressionheader 302 of FIG. 3B.

The extended compression header 607 may be used between a transmitterand a receiver when a compression context ID and a portion of the datapacket to which the compression context ID is to be applied have notbeen pre-negotiated. In other words, in the example shown in FIG. 6C,the transmitter may convey to the receiver various identifiedcompression options that the receiver may apply to one or more portionsof the transmitted data packet.

Therefore, the extended compression header 607 includes a packet actionfield 655 which has a corresponding value 656 indicating thatcompression is enabled for the data packet. The extended compressionheader 607 also includes a CRC field 660 which includes a correspondingCRC value 661. Following the CRC field 660, the extended compressionheader 607 includes an extension field 665. Because the transmitter hasneed to convey compression options to the receiver in the extendedcompression header 607, the extension field 665 has a value 666 thatindicates that an extension header is present (in the form of optionfield 670, value field 675, length indicator field 680, and length field685). In this example, the option field 670 indicates (in its value 671)that a portion of the data packet (portion 1) is to be compressed usingthe value 676 in value field 675. The value 676 indicates thecompression context ID to be applied. The length indicator field 680indicates in its value 681 whether the compression context ID is to beapplied to just a portion of the data packet or to the remainder of thedata packet. In this case, value 681 indicates that the compressioncontext ID is to be applied to just a portion of the data packet. Thelength of the portion of the data packet to which the compressioncontext ID is to be applied is indicated in the value 686 of the lengthfield 685. In this example, no additional compression options need to beconveyed to the receiver, and so the extended compression header 607includes a second extension field 690 which indicates in itscorresponding value 691 that additional extension headers are absent.

Assuming the transmitter and the receiver intend to use the samecompression scheme for successive data packets, future data packets mayinclude a simplified versions of the extended compression header 608.Extended compression header 608 includes a packet action field 657 witha value 658 which indicates that compression is enabled for the datapacket. Extended compression header 608 also includes a CRC field 662with a CRC value 663. And, because these successive data packets neednot convey additional compression options, the extended compressionheader 608 includes an extension field 667 having a value 668 indicatingthat the extension header is absent.

FIG. 7A and FIG. 7B show examples of a compression header, in accordancewith aspects of the present disclosure. In particular, FIG. 7Aillustrates a compression header framework 700 that includes an extendedcompression header 705 to be used on a first data packet, and anextended compression header 706 to be used on subsequently transmitteddata packets. For simplicity, only a portion of the extended compressionheaders 705, 706 are illustrated in FIG. 7A. The extended compressionheaders 705, 706 may be examples of the extended compression header 300of FIG. 3A.

The extended compression header 705 may be used between a transmitterand a receiver when a compression context ID and a portion of the datapacket to which the compression context ID is to be applied have notbeen pre-negotiated, and when different compression contexts are to beapplied to different portions of the transmitted data packet.

Therefore, the extended compression header 705 includes a packet actionfield 710 which has a corresponding value 711 indicating thatcompression is enabled for the data packet. The extended compressionheader 705 also includes a CRC field 715 which includes a correspondingCRC value 716. Following the CRC field 715, the extended compressionheader 705 includes an extension field 720. Because the transmitter hasneed to convey compression options to the receiver in the extendedcompression header 705, the extension field 720 has a value 721 thatindicates that an extension header is present (in the form of optionfield 725 and value field 730). In this example, the option field 725indicates (in its value 726) that a portion of the data packet (portion1) is to be compressed using the value 731 in value field 730. The value731 indicates the compression context ID to be applied to a length ofthe data packet.

The extended compression header 705 also includes a second extensionfield 735 which indicates, by its value 736, that an additionalcompression option is included in an additional extension header. Inthis second extension header, option field 740 indicates (by its value741) that the remainder of the data packet is to be compressed using adifferent compression context identified in the value 746 of value field745.

Because no additional compression options need to be conveyed to thereceiver, the extended compression header 705 includes a third extensionfield 750 which indicates in its corresponding value 751 that additionalextension headers are absent.

Assuming the transmitter and the receiver intend to use the samecompression scheme for successive data packets, future data packets mayinclude a simplified version of the extended compression header 706.Extended compression header 706 includes a packet action field 712 witha value 713 which indicates that compression is enabled for the datapacket. Extended compression header 706 also includes a CRC field 715with a CRC value 718. And, because these successive data packets neednot convey additional compression options, the extended compressionheader 706 includes an extension field 722 having a value 723 indicatingthat the extension header is absent.

FIG. 7B illustrates a compression header framework 701 that includes anextended compression header 707 to be used on a first data packet, andan extended compression header 708 to be used on subsequentlytransmitted data packets. For simplicity, only a portion of the extendedcompression headers 707, 708 are illustrated in FIG. 7B. The extendedcompression headers 707, 708 may be examples of the extended compressionheader 302 of FIG. 3B.

The extended compression header 707 may be used between a transmitterand a receiver when a compression context ID and a portion of the datapacket to which the compression context ID is to be applied have notbeen pre-negotiated.

The extended compression header 707 includes a packet action field 755which has a corresponding value 756 indicating that compression isenabled for the data packet. The extended compression header 707 alsoincludes a CRC field 760 which includes a corresponding CRC value 761.Following the CRC field 760, the extended compression header 707includes an extension field 765. Because the transmitter has need toconvey compression options to the receiver in the extended compressionheader 707, the extension field 765 has a value 766 that indicates thatan extension header is present (in the form of option field 770, valuefield 775, length indicator field 777, and length field 780). In thisexample, the option field 770 indicates (in its value 771) that aportion of the data packet (portion 1) is to be compressed using thevalue 776 in value field 775. The value 776 indicates the compressioncontext ID to be applied. The length indicator field 777 indicates inits value 778 whether the compression context ID is to be applied tojust a portion of the data packet or to the remainder of the datapacket. In this case, value 778 indicates that the compression contextID is to be applied to just a portion of the data packet. The length ofthe portion of the data packet to which the compression context ID is tobe applied is indicated in the value 781 of the length field 780.

The extended compression header 707 also includes a second extensionfield 782 which indicates, by its value 783, that an additionalcompression option is included in an additional extension header. Inthis second extension header, option field 785 indicates (by its value786) that a second portion of the data packet is to be compressed usinga different compression context. The different compression context to beapplied is identified in the value 788 of value field 787. The lengthindicator field 790 indicates by its value 791 that the compressioncontext ID identified in value 788 is to be applied to the remainder ofthe data packet. Thus, no additional length field is necessary.

Because no additional compression options need to be conveyed to thereceiver, the extended compression header 707 includes a third extensionfield 795 which indicates in its corresponding value 796 that additionalextension headers are absent.

Assuming the transmitter and the receiver intend to use the samecompression scheme for successive data packets, future data packets mayinclude a simplified version of the extended compression header 708.Extended compression header 708 includes a packet action field 757 witha value 758 which indicates that compression is enabled for the datapacket. Extended compression header 708 also includes a CRC field 762with a CRC value 763. And, because these successive data packets neednot convey additional compression options, the extended compressionheader 708 includes an extension field 767 having a value 768 indicatingthat the extension header is absent.

FIG. 8 shows an example of a compression header, in accordance withaspects of the present disclosure. In particular, FIG. 8 illustrates acompression header framework 800 that includes an extended compressionheader 805 applied to a first data packet, and an extended compressionheader 806 applied to subsequently transmitted data packets. Forsimplicity, only a portion of the extended compression headers 805, 806are illustrated in FIG. 8. The extended compression headers 805, 806 maybe examples of either of the extended compression headers 300, 302 ofFIGS. 3A and 3B.

The extended compression header 805 may be used between a transmitterand a receiver when multiple compression context IDs and multipleportions of the data packet to which the compression context IDs are tobe applied have been pre-negotiated. In other words, in the exampleshown in FIG. 6, both the receiver and the transmitter already know whattypes of compression schemes to be applied and to what portions of thedata packet the compression schemes are to be applied. Thus, there is noneed to convey the compression contexts or other compression-relatedvalues in the extended compression header 805.

Therefore, the extended compression header 805 includes a packet actionfield 810 which has a corresponding value 811 indicating thatcompression is enabled for the data packet. The extended compressionheader 805 also includes a CRC field 815 which includes a correspondingCRC value 816. Following the CRC field 815, the extended compressionheader 805 includes an extension field 820. Because no compressionoptions need be conveyed in the extended compression header 805 (as aresult of the options being pre-negotiated), the value 821 for theextension field 820 indicates that the extension header is absent.

Assuming the transmitter and the receiver intend to use the samecompression schemes for successive data packets, future data packets mayinclude a simplified versions of the extended compression header 806.Extended compression header 806 includes a packet action field 860 witha value 861 which indicates that compression is enabled for the datapacket. Extended compression header 806 also includes a CRC field 865with a CRC value 866. And, because these successive data packets neednot convey additional compression options, the extended compressionheader 806 includes an extension field 870 having a value 871 indicatingthat the extension header is absent.

FIG. 9 shows a block diagram of a wireless device 900 configured forevolved data compression scheme signaling in accordance with variousaspects of the present disclosure. Wireless device 900 may be an exampleof aspects of a UE 115 described with reference to FIGS. 1-4. Wirelessdevice 900 may include a receiver 905, an evolved data compressionmodule 910, or a transmitter 915. Wireless device 900 may also include aprocessor. Each of these components may be in communication with eachother.

The components of wireless device 900 may, individually or collectively,be implemented with at least one application specific integrated circuit(ASIC) adapted to perform some or all of the applicable functions inhardware. Alternatively, the functions may be performed by one or moreother processing units (or cores), on at least one IC. In otherembodiments, other types of integrated circuits may be used (e.g.,Structured/Platform ASICs, a field programmable gate array (FPGA), oranother semi-custom IC), which may be programmed in any manner known inthe art. The functions of each unit may be implemented, in whole or inpart, with instructions embodied in a memory, formatted to be executedby one or more general or application-specific processors.

The receiver 905 may receive information such as packets, user data, orcontrol information associated with various information channels (e.g.,control channels, data channels, and information related to evolved datacompression scheme signaling, etc.). Information may be passed on to theevolved data compression module 910, and to other components of wirelessdevice 900.

The evolved data compression module 910 may receive a compressioncapability request related to a capability for compressing a payload ofa wireless data transmission, identify at least one compressioncapability parameter based on the compression capability request, andtransmit a compression capability response based at least in part on thecompression capability request and the at least one compressioncapability parameter.

The transmitter 915 may transmit signals received from other componentsof wireless device 900. In some embodiments, the transmitter 915 may becollocated with the receiver 905 in a transceiver module. Thetransmitter 915 may include a single antenna, or it may include aplurality of antennas.

FIG. 10 shows a block diagram of a wireless device 1000 for evolved datacompression scheme signaling in accordance with various aspects of thepresent disclosure. Wireless device 1000 may be an example of aspects ofa wireless device 900 or a UE 115 described with reference to FIGS. 1-5.Wireless device 1000 may include a receiver 905-a, an evolved datacompression module 910-a, or a transmitter 915-a. Wireless device 1000may also include a processor. Each of these components may be incommunication with each other. The evolved data compression module 910-amay include a capability request module 1005, a capabilityidentification module 1010, and/or a capability response module 1015.

The components of wireless device 1000 may, individually orcollectively, be implemented with at least one ASIC adapted to performsome or all of the applicable functions in hardware. Alternatively, thefunctions may be performed by one or more other processing units (orcores), on at least one IC. In other embodiments, other types ofintegrated circuits may be used (e.g., Structured/Platform ASICs, anFPGA, or another semi-custom IC), which may be programmed in any mannerknown in the art. The functions of each unit may be implemented, inwhole or in part, with instructions embodied in a memory, formatted tobe executed by one or more general or application-specific processors.

The receiver 905-a may receive information which may be passed on toevolved data compression module 910-a, and to other components of a UE115. The evolved data compression module 910-a may perform theoperations described above with reference to FIG. 9. The transmitter915-a may transmit signals received from other components of wirelessdevice 1000.

The capability request module 1005 may receive a compression capabilityrequest related to a capability for compressing a payload of a wirelessdata transmission as described above with reference to FIGS. 2-4. Insome examples, the capability relates to a compression rate supportparameter and/or a compression context prefill configuration.

The capability identification module 1010 may identify at least onecompression capability parameter based on the compression capabilityrequest as described above with reference to FIGS. 2-4.

The capability response module 1015 may transmit a compressioncapability response based at least in part on the compression capabilityrequest and the at least one compression capability parameter asdescribed above with reference to FIGS. 2-4.

FIG. 11 shows a block diagram 1100 of an evolved data compression module910-b which may be a component of a wireless device 900 or a wirelessdevice 1000 for evolved data compression scheme signaling in accordancewith various aspects of the present disclosure. The evolved datacompression module 910-b may be an example of aspects of an evolved datacompression module 910 described with reference to FIGS. 9-10. Theevolved data compression module 910-b may include a capability requestmodule 1005-a, a capability identification module 1010-a, and acapability response module 1015-a. Each of these modules may perform thefunctions described above with reference to FIG. 10. The evolved datacompression module 910-b may include a compression configuration module1105, a compression module 1110, a decompression module 1115, anextended header module 1120, a context ID module 1125, a compressioncontrol module 1130, a compression status module 1135, and/or acompression enable/disable module 1140.

The components of the evolved data compression module 910-b may,individually or collectively, be implemented with at least one ASICadapted to perform some or all of the applicable functions in hardware.Alternatively, the functions may be performed by one or more otherprocessing units (or cores), on at least one IC. In other embodiments,other types of integrated circuits may be used (e.g.,Structured/Platform ASICs, an FPGA, or another semi-custom IC), whichmay be programmed in any manner known in the art. The functions of eachunit may be implemented, in whole or in part, with instructions embodiedin a memory, formatted to be executed by one or more general orapplication-specific processors.

The compression configuration module 1105 may receive a compressionconfiguration request as described above with reference to FIGS. 2-4.The compression configuration module 1105 may transmit a compressionconfiguration request based at least in part on the selected compressionconfiguration. The compression configuration module 1105 may transmit acompression configuration confirmation based at least in part on thecompression configuration request. The compression configuration module1105 may transmit a compression configuration rejection based at leastin part on the compression configuration request. The compressionconfiguration module 1105 may receive a compression configurationconfirmation based at least in part on the compression configurationrequest. The compression configuration module 1105 may receive acompression configuration rejection based at least in part on thecompression configuration request.

The compression module 1110 may transmit a compressed packet based atleast in part on the compression capability response as described abovewith reference to FIGS. 2-4. The compression module 1110 may reset acompression queue based on an indication that a compressed packet hasbeen dropped. The compression module 1110 may store a compressed versionof a packet. The compression module 1110 may store an uncompressedversion of the packet. The compression module 1110 may reset a contextID based on the uncompressed version of the packet. The compressionmodule 1110 may determine that a packet is scheduled for immediatetransmission. The compression module 1110 may compress the packet basedon the determination that the packet is scheduled for immediatetransmission.

The decompression module 1115 may receive a compressed packet based atleast in part on the compression capability response as described abovewith reference to FIGS. 2-4. The decompression module 1115 may receive acompressed packet, wherein the compressed packet is compressedimmediately prior to transmission.

The extended header module 1120 may be configured such that thecompressed packet may include one or more extended compression headerfields indicating at least one of a compression context reset request, acompression disable request associated with a number of subsequentpackets, a compression context synchronization indication, a compressioncontext freeze request, a multi-part compression indicator associatedwith a plurality of compression contexts, or a compression metadataindicator as described above with reference to FIGS. 2-4.

The context ID module 1125 may transmit a context ID save confirmationrequest as described above with reference to FIGS. 2-4. The context IDmodule 1125 may receive a context ID save confirmation. The context IDmodule 1125 may transmit a context ID save confirmation.

The compression control module 1130 may transmit a compression controlmessage as described above with reference to FIGS. 2-4. In someexamples, transmitting the compression control message comprisestransmitting the compression control message on a high priority radiobearer. In some examples, the compression control message may be basedat least in part on a determination that an amount of available wirelessdevice processing resources may be below a threshold. In some examples,the compression control message may be based on a determination that thewireless device has failed to decompress or decode a number of packets.In some examples, the compression control message comprises at least oneof a compression state indication, a compression scope indication, adata compression threshold, a compression enable/disable indication, acompressed packet ratio, or context ID reset request.

The compression status module 1135 may transmit a compression statusindication as described above with reference to FIGS. 2-4. In someexamples, the compression status indication comprises at least one of aciphered PDCP control PDU type, an unciphered PDCP control PDU type, asequence number, or a compression enable/disable indication. When thecompression status indication indicates that compression has beenenabled for a radio bearer, the compression status module 1135 maytransmit the compression status indication before transmission of afirst compressed data PDU. When the compression status indicationindicates that compression has been disabled for a radio bearer, thecompression status module 1135 may transmit the compression statusindication after transmission of a last compressed data PDU. In certaincases, when compression is established on a radio bearer in the sameconfiguration message, the compression status indication indicating thatcompression has been enabled may not actually be transmitted.

The compression enable/disable module 1140 may transmit a compressionenable request or a compression disable request based at least in parton at least one of a processing limitation, a traffic type, or adetermination that a resource grant volume is sufficient to clear anuncompressed memory buffer during one or more periodic intervals asdescribed above with reference to FIGS. 2-4.

FIG. 12 shows a diagram of a portion of a system 1200 including a UE 115configured for evolved data compression scheme signaling in accordancewith various aspects of the present disclosure. System 1200 may includeUE 115-d, which may be an example of a wireless device 900, a wirelessdevice 1000, or a UE 115 described above with reference to FIGS. 1, 2and 9-10. UE 115-d may include an evolved data compression module 1210,which may be an example of an evolved data compression module 910described with reference to FIGS. 9-11. UE 115-d may include a discardtimer module 1225. UE 115-d may include components for bi-directionalvoice and data communications including components for transmittingcommunications and components for receiving communications. For example,UE 115-d may communicate bi-directionally with base station 105-d or UE115-e.

The discard timer module 1225 may be used to discard PDCP PDUs after theexpiration of a time-out timer. In some cases, discard timer module 1225may disable a PDCP discard timer based at least in part on thecompression capability request as described above with reference toFIGS. 2-4.

UE 115-d may include a processor module 1205, and memory 1215 (e.g.,including software (SW)) 1220, a transceiver module 1235, and one ormore antenna(s) 1240, each of which may communicate, directly orindirectly, with one another (e.g., via buses 1245). The transceivermodule 1235 may communicate bi-directionally, via the antenna(s) 1240 orwired or wireless links, with one or more networks, as described above.For example, the transceiver module 1235 may communicatebi-directionally with a base station 105 or another UE 115. Thetransceiver module 1235 may include a modem to modulate the packets andprovide the modulated packets to the antenna(s) 1240 for transmission,and to demodulate packets received from the antenna(s) 1240. While UE115-d may include a single antenna 1240, UE 115-d may also have multipleantennas 1240 capable of concurrently transmitting or receiving multiplewireless transmissions.

The memory 1215 may include random access memory (RAM) and read onlymemory (ROM). The memory 1215 may store computer-readable,computer-executable software/firmware code 1220 including instructionsthat, when executed, cause the processor module 1205 to perform variousfunctions described herein (e.g., evolved data compression schemesignaling, etc.). Alternatively, the software/firmware code 1220 may notbe directly executable by the processor module 1205 but cause a computer(e.g., when compiled and executed) to perform functions describedherein. The processor module 1205 may include an intelligent hardwaredevice, (e.g., a central processing unit (CPU), a microcontroller, anASIC, etc.).

FIG. 13 shows a block diagram of a wireless device 1300 configured forevolved data compression scheme signaling in accordance with variousaspects of the present disclosure. Wireless device 1300 may be anexample of aspects of a base station 105 described with reference toFIGS. 1-2, and 9-12. Wireless device 1300 may include a receiver 1305, abase station evolved data compression module 1310, or a transmitter1315. Wireless device 1300 may also include a processor. Each of thesecomponents may be in communication with each other.

The components of wireless device 1300 may, individually orcollectively, be implemented with at least one ASIC adapted to performsome or all of the applicable functions in hardware. Alternatively, thefunctions may be performed by one or more other processing units (orcores), on at least one IC. In other embodiments, other types ofintegrated circuits may be used (e.g., Structured/Platform ASICs, anFPGA, or another semi-custom IC), which may be programmed in any mannerknown in the art. The functions of each unit may be implemented, inwhole or in part, with instructions embodied in a memory, formatted tobe executed by one or more general or application-specific processors.

The receiver 1305 may receive information such as packets, user data, orcontrol information associated with various information channels (e.g.,control channels, data channels, and information related to evolved datacompression scheme signaling, etc.). Information may be passed on to thebase station evolved data compression module 1310, and to othercomponents of wireless device 1300.

The base station evolved data compression module 1310 may transmit acompression capability request related to a capability for compressing apayload of a wireless data transmission, receive a compressioncapability response based at least in part on the compression capabilityrequest, and select a compression configuration based at least in parton the compression capability response.

The transmitter 1315 may transmit signals received from other componentsof wireless device 1300. In some embodiments, the transmitter 1315 maybe collocated with the receiver 1305 in a transceiver module. Thetransmitter 1315 may include a single antenna, or it may include aplurality of antennas.

FIG. 14 shows a block diagram of a wireless device 1400 for evolved datacompression scheme signaling in accordance with various aspects of thepresent disclosure. Wireless device 1400 may be an example of aspects ofa wireless device 1300 or a base station 105 described with reference toFIGS. 1, 2, 4, and 9-13. Wireless device 1400 may include a receiver1305-a, a base station evolved data compression module 1310-a, or atransmitter 1315-a. Wireless device 1400 may include a processor. Eachof these components may be in communication with each other. The basestation evolved data compression module 1310-a may include a BScapability request module 1405, a BS capability response module 1410,and a BS compression configuration module 1415.

The components of wireless device 1400 may, individually orcollectively, be implemented with at least one ASIC adapted to performsome or all of the applicable functions in hardware. Alternatively, thefunctions may be performed by one or more other processing units (orcores), on at least one IC. In other embodiments, other types ofintegrated circuits may be used (e.g., Structured/Platform ASICs, anFPGA, or another semi-custom IC), which may be programmed in any mannerknown in the art. The functions of each unit may be implemented, inwhole or in part, with instructions embodied in a memory, formatted tobe executed by one or more general or application-specific processors.

The receiver 1305-a may receive information which may be passed on tobase station evolved data compression module 1310-a, and to othercomponents of a base station 105. The base station evolved datacompression module 1310-a may perform the operations described abovewith reference to FIG. 13. The transmitter 1315-a may transmit signalsreceived from other components of wireless device 1400.

The BS capability request module 1405 may transmit a compressioncapability request related to a capability for compressing a payload ofa wireless data transmission as described above with reference to FIGS.2-4.

The BS capability response module 1410 may receive a compressioncapability response based at least in part on the compression capabilityrequest as described above with reference to FIGS. 2-4.

The BS compression configuration module 1415 may select a compressionconfiguration based at least in part on the compression capabilityresponse as described above with reference to FIGS. 2-4.

FIG. 15 shows a block diagram 1500 of a base station evolved datacompression module 1310-b which may be a component of a wireless device1300 or a wireless device 1400 for evolved data compression schemesignaling in accordance with various aspects of the present disclosure.The base station evolved data compression module 1310-b may be anexample of aspects of a base station evolved data compression module1310 described with reference to FIGS. 13-14. The base station evolveddata compression module 1310-b may include a BS capability requestmodule 1405-a, a BS capability response module 1410-a, and a BScompression configuration module 1415-a. Each of these modules mayperform the functions described above with reference to FIG. 14. Thebase station evolved data compression module 1310-b may include a BSdecompression module 1505, a BS compression module 1510, a BS extendedheader module 1515, a BS context ID module 1520, a BS compressioncontrol module 1525, a BS compression status module 1530, a BScompression enable/disable module 1535, and/or a BS discard timer module1540.

The components of the base station evolved data compression module1310-b may, individually or collectively, be implemented with at leastone ASIC adapted to perform some or all of the applicable functions inhardware. Alternatively, the functions may be performed by one or moreother processing units (or cores), on at least one IC. In otherembodiments, other types of integrated circuits may be used (e.g.,Structured/Platform ASICs, an FPGA, or another semi-custom IC), whichmay be programmed in any manner known in the art. The functions of eachunit may be implemented, in whole or in part, with instructions embodiedin a memory, formatted to be executed by one or more general orapplication-specific processors.

The BS decompression module 1505 may receive a compressed packet basedat least in part on the compression capability response as describedabove with reference to FIGS. 2-4.

The BS compression module 1510 may be used to transmit a compressedpacket based at least in part on the compression capability response asdescribed above with reference to FIGS. 2-4.

The BS extended header module 1515 may be configured such that thecompressed packet may include one or more extended compression headerfields indicating at least one of a compression context reset request, acompression disable request associated with a number of subsequentpackets, a compression context synchronization indication, a compressioncontext freeze request, a multi-part compression indicator associatedwith a plurality of compression contexts, or a compression metadataindicator as described above with reference to FIGS. 2-4.

The BS context ID module 1520 may receive a context ID save confirmationrequest as described above with reference to FIGS. 2-4. The BScompression control module 1525 may transmit a compression controlmessage as described above with reference to FIGS. 2-4. The BScompression status module 1530 may transmit a compression statusindication as described above with reference to FIGS. 2-4.

The BS compression enable/disable module 1535 may transmit a compressionenable request or a compression disable request based at least in parton at least one of a processing limitation, a traffic type, or adetermination that a resource grant volume is sufficient to clear anuncompressed memory buffer during one or more periodic intervals asdescribed above with reference to FIGS. 2-4. The BS discard timer module1540 may disable a PDCP discard timer based at least in part on thecompression capability request as described above with reference toFIGS. 2-4.

FIG. 16 shows a diagram of a system 1600 including a base station 105configured for evolved data compression scheme signaling in accordancewith various aspects of the present disclosure. System 1600 may includebase station 105-e, which may be an example of a wireless device 1300, awireless device 1400, or a base station 105 described above withreference to FIGS. 1, 2 and 4-15. Base station 105-e may include a basestation evolved data compression module 1610, which may be an example ofa base station evolved data compression module 1310 described withreference to FIGS. 13-15. Base station 105-e may include components forbi-directional voice and data communications including components fortransmitting communications and components for receiving communications.For example, base station 105-e may communicate bi-directionally with UE115-f or UE 115-g.

In some cases, base station 105-e may have one or more wired backhaullinks. Base station 105-e may have a wired backhaul link (e.g., S1interface, etc.) to the core network 130. Base station 105-e may alsocommunicate with other base stations 105, such as base station 105-e andbase station 105-f via inter-base station backhaul links (e.g., an X2interface). Each of the base stations 105 may communicate with UEs 115using the same or different wireless communications technologies. Insome cases, base station 105-e may communicate with other base stationssuch as 105-f or 105-g utilizing base station communication module 1625.In some embodiments, base station communication module 1625 may providean X2 interface within an LTE/LTE-A wireless communication networktechnology to provide communication between some of the base stations105. In some embodiments, base station 105-e may communicate with otherbase stations through core network 130. In some cases, base station105-e may communicate with the core network 130 through networkcommunications module 1630.

The base station 105-e may include a processor module 1605, memory 1615(e.g., including software (SW) 1620), transceiver modules 1635, andantenna(s) 1640, which each may be in communication, directly orindirectly, with one another (e.g., over bus system 1645). Thetransceiver modules 1635 may be configured to communicatebi-directionally, via the antenna(s) 1640, with the UEs 115, which maybe multi-mode devices. The transceiver module 1635 (or other componentsof the base station 105-e) may be configured to communicatebi-directionally, via the antennas 1640, with one or more other basestations (not shown). The transceiver module 1635 may include a modemconfigured to modulate the packets and provide the modulated packets tothe antennas 1640 for transmission, and to demodulate packets receivedfrom the antennas 1640. The base station 105-e may include multipletransceiver modules 1635, each with one or more associated antennas1640. The transceiver module may be an example of a combined receiver1305 and transmitter 1315 of FIG. 13.

The memory 1615 may include RAM and ROM. The memory 1615 may also storecomputer-readable, computer-executable software code 1620 containinginstructions that are configured to, when executed, cause the processormodule 1610 to perform various functions described herein (e.g., evolveddata compression scheme signaling, selecting coverage enhancementtechniques, call processing, database management, message routing,etc.). Alternatively, the software 1620 may not be directly executableby the processor module 1605 but be configured to cause the computer,e.g., when compiled and executed, to perform functions described herein.The processor module 1605 may include an intelligent hardware device,(e.g., a CPU, a microcontroller, an ASIC, etc.). The processor module1605 may include various special purpose processors such as encoders,queue processing modules, base band processors, radio head controllers,digital signal processor (DSPs), and the like.

The base station communications module 1625 may manage communicationswith other base stations 105. The communications management module mayinclude a controller or scheduler for controlling communications withUEs 115 in cooperation with other base stations 105. For example, thebase station communications module 1625 may coordinate scheduling fortransmissions to UEs 115 for various interference mitigation techniquessuch as beamforming or joint transmission.

FIG. 17 shows a block diagram 1700 of a device 1705 configured for usein wireless communication, in accordance with aspects of the presentdisclosure. The device 1705 may be an example of one or more aspects ofa UE 115 described with reference to FIGS. 1, 2, and 5. Alternatively,the device 1705 may be an example of one or more aspects of a basestation 105 of FIGS. 1, 2, and 5. The device 1705 may include a receiver1710, an eDCS header module 1715, or a transmitter 1720. The device 1705may also be or include a processor (not shown). Each of these modulesmay be in communication with each other.

The components of the device 1705 may, individually or collectively, beimplemented using one or more application-specific integrated circuits(ASICs) adapted to perform some or all of the applicable functions inhardware. Alternatively, the functions may be performed by one or moreother processing units (or cores), on one or more integrated circuits.In other examples, other types of integrated circuits may be used (e.g.,Structured/Platform ASICs, Field Programmable Gate Arrays (FPGAs), andother Semi-Custom ICs), which may be programmed in any manner known inthe art. The functions of each module may also be implemented, in wholeor in part, with instructions embodied in a memory, formatted to beexecuted by one or more general or application-specific processors.

The receiver 1710 may receive information such as packets, user data,and/or control information associated with various information channels(e.g., control channels, data channels, etc.). The receiver 1710 may beconfigured to receive data packets that have been partially orcompletely compressed, as indicated by an extended compression header.Information may be passed on to the eDCS header module 1715, and toother components of the device 1705.

The eDCS header module 1715 may be used to identify or apply acompression option. The compression option may instruct a receiver toreset its compression context, for example. Or, the compression optionmay include disabling the transmission of the extended compressionheader for a specified number of data packets. The compression optionmay be to request that a receiver check point a compression context. Or,the compression option may be to request that a compression context befrozen and used for a specific number of data packets. The compressionoption may indicate that a compression context is to be applied to aportion of a data packet, or even to the remaining portion of a datapacket. Additionally, the compression option may indicate that anextended compression header will include no compression header metadata.

The eDCS header module 1715 may include the identified compressionoption in an extended compression header which may be included with adata packet during transmission. Additionally, the eDCS header module1715 may be configured to apply a received compression option.

The transmitter 1720 may transmit the one or more signals received fromother components of the device 1705. The transmitter 1720 may transmitdata packets that are either partially or completely compressed, asindicated by an attached extended compression header. In some examples,the transmitter 1720 may be collocated with the receiver 1710 in atransceiver.

FIG. 18 shows a block diagram 1800 of a device 1805 configured for usein wireless communication, in accordance with aspects of the presentdisclosure. The device 1805 may be an example of one or more aspects ofa UE 115 described with reference to FIGS. 1, 2, and 5. The device 1805may also be an example of one or more aspects of a base station 105described with reference to FIGS. 1, 2, and 5. Additionally, the device1805 may be an example of a device 1705 described with reference to FIG.17. The device 1805 may include a receiver 1810, an eDCS header module1815, or a transmitter 1820, which may be examples of the correspondingmodules of device 1705. The device 1805 may also include a processor(not shown). Each of these components may be in communication with eachother. The eDCS header module 1815 may include a compression optionmodule 1825 or an extended compression header module 1830. The receiver1810 and the transmitter 1820 may perform the functions of the receiver1710 and the transmitter 1720, of FIG. 17, respectively.

The compression option module 1825 may be used to determine anappropriate compression option and value to include in an extendedcompression header. For example, the compression option module 1825 maybe used to identify that the device 1805 and a communicating device areout of sync, and thus a compression option that instructs a receiver toreset its compression context may be appropriate. Other options that maybe identified by the compression option module 1825 may include optionsfor disabling the transmission of the extended compression header for aspecified number of data packets, options for requesting that a receivercheck point a compression context, or options for requesting that acompression context be frozen and used for a specific number of datapackets. The compression option may indicate that a compression contextis to be applied to a portion of a data packet, or even to the remainingportion of a data packet. Additionally, the compression option mayindicate that an extended compression header will include no compressionheader metadata.

The extended compression header module 1830 may be used to generate anextended compression header in which one or more identified compressionoptions may be included. The extended compression header generated bythe extended compression header module 1830 may be coupled with a datapacket for transmission by the transmitter module 1820.

FIG. 19 shows a block diagram 1900 of a wireless communication device,in accordance with aspects of the present disclosure. Wirelesscommunication device may include a UE 115-h, which may be an example ofthe UEs 115 FIGS. 1, 2, and 5. UE 115-h may also be an example of one ormore aspects of devices 1705 and 1805 of FIGS. 17 and 18. The UE 115-hmay be configured to implement or facilitate at least some of the UE ordevice features and functions described with reference to FIGS. 1through 18.

The UE 1910 may include components for bi-directional voice and datacommunications including components for transmitting communications andcomponents for receiving communications. The UE 115-h may include UEantenna(s) 1940, a UE transceiver module 1935, a UE processor module1905, and UE memory 1915 (including software (SW) 1920), which each maycommunicate, directly or indirectly, with each other (e.g., via one ormore buses 1945). The UE transceiver module 1935 may be configured tocommunicate bi-directionally, via the UE antenna(s) 1940 and/or one ormore wired or wireless links, with one or more networks, as describedabove. For example, the UE transceiver module 1935 may be configured tocommunicate bi-directionally with base stations 105, 235, 405 withreference to FIGS. 1, 2, and 4. The UE transceiver module 1935 mayinclude a modem configured to modulate the packets and provide themodulated packets to the UE antenna(s) 1940 for transmission, and todemodulate packets received from the UE antenna(s) 1940. While the UE115-h may include a single UE antenna 1940, the UE 115-h may havemultiple UE antennas 1940 capable of concurrently transmitting and/orreceiving multiple wireless transmissions. The UE transceiver module1935 may be capable of concurrently communicating with one or more basestations 105, 235, 405 via multiple component carriers.

The UE 115-h may include a UE eDCS header module 1930, which may performthe functions described above for the eDCS header modules 915, 1015 ofdevices 905 and 1005, respectively, when devices 905 and 1005 functionor are included as a UE, as described in relation to FIGS. 9 and 10. TheUE 115-h may also include a UE compression/decompression module 1950.The UE compression/decompression module 1950 may be used by the UE 115-hto compress portions or the entirety of a data packet in accordance tocompression options identified with relation to the data packet.Additionally, the UE compression/decompression module 1950 may be usedby the UE 115-h to decompress portions of a data packet in accordance tocompression options received in an extended compression header with thedata packet.

The UE memory 1915 may include random access memory (RAM) and read-onlymemory (ROM). The UE memory 1915 may store computer-readable,computer-executable software/firmware code 1920 containing instructionsthat are configured to, when executed, cause the UE processor module1905 to perform various functions described herein (e.g., identifycompression options, generate extended compression headers and compressor decompress data packets in accordance with the compression optionsincluded in the extended compression headers, etc.). Alternatively, thecomputer-readable, computer-executable software/firmware code 1920 maynot be directly executable by the UE processor module 1905 but beconfigured to cause a computer (e.g., when compiled and executed) toperform functions described herein. The UE processor module 1905 mayinclude an intelligent hardware device, (e.g., a central processing unit(CPU), a microcontroller, an application-specific integrated circuit(ASIC), etc.)

FIG. 20 shows a block diagram 2000 of a base station 105-h (e.g., a basestation forming part or all of an eNB) for use in wirelesscommunication, in accordance with aspects of the present disclosure. Insome examples, the base station 105-h may be an example of aspects ofone or more of the base stations 105 described with reference to FIGS.1, 2, and 5. Base station 105-h may also be an example of one or moreaspects of devices 1705, 1805 of FIGS. 17 and 18. The base station 105-hmay be configured to implement or facilitate at least some of the basestation or device features and functions described with reference toFIGS. 1 through 19.

The base station 105-h may include a processor module 2010, a memory2020, at least one base station transceiver module (represented by basestation transceiver module(s) 2050), at least one antenna (representedby antenna(s) 2055), a base station eDCS header module 2015, or a basestation compression/decompression module 2070. The base station 105-hmay also include one or more of a base station communications module2030 or a network communications module 2040. Each of these modules maybe in communication with each other, directly or indirectly, over one ormore buses 2035.

The memory 2020 may include random access memory (RAM) and/or read-onlymemory (ROM). The memory 2020 may store computer-readable,computer-executable software/firmware code 2025 containing instructionsthat are configured to, when executed, cause the processor module 2010to perform various functions described herein related to wirelesscommunication (e.g., identify compression options, generate extendedcompression headers and compress or decompress data packets inaccordance with the compression options included in the extendedcompression headers, etc.). Alternatively, the computer-readable,computer-executable software/firmware code 2025 may not be directlyexecutable by the processor module 2010 but be configured to cause thebase station 105-h (e.g., when compiled and executed) to perform variousof the functions described herein.

The processor module 2010 may include an intelligent hardware device(e.g., a central processing unit (CPU), a microcontroller, an ASIC,etc.). The processor module 2010 may process information receivedthrough the base station transceiver module(s) 2050, the base stationcommunications module 2030, or the network communications module 2040.The processor module 2010 may also process information to be sent to thetransceiver module(s) 2050 for transmission through the antenna(s) 2055,to the base station communications module 2030, for transmission to oneor more other base stations 2060 and 2065, or to the networkcommunications module 2040 for transmission to a core network 130-d,which may be an example of one or more aspects of the core network 130,230 described with reference to FIGS. 1 and 2. The processor module 2010may handle, alone or in connection with the base station eDCS headermodule 2015 and the base station compression/decompression module 2070,various aspects of eDCS compression, such as identifying compressionoptions, generating extended compression headers and compressing ordecompressing data packets in accordance with the compression optionsincluded in the extended compression headers.

The base station transceiver module(s) 2050 may include a modemconfigured to modulate packets and provide the modulated packets to theantenna(s) 2055 for transmission, and to demodulate packets receivedfrom the antenna(s) 2055. The base station transceiver module(s) 2050may, in some examples, be implemented as one or more base stationtransmitter modules and one or more separate base station receivermodules. The base station transceiver module(s) 2050 may supportcommunications in a first radio frequency spectrum band or a secondradio frequency spectrum band. The base station transceiver module(s)2050 may be configured to communicate bi-directionally, via theantenna(s) 2055, with one or more UEs or apparatuses, such as one ormore of the UEs 115 described with reference to FIGS. 1, 2, and 5. Thebase station 105-h may, for example, include multiple antennas 2055(e.g., an antenna array). The base station 2005 may communicate with thecore network 2045 through the network communications module 2040. Thebase station 105-h may also communicate with other base stations, suchas the base stations 105-i and 105-j, using the base stationcommunications module 2030.

The base station eDCS header module 2015 may be configured to perform orcontrol some or all of the features or functions described withreference to FIGS. 1 through 10 related to eDCS compression. In someexamples, the base station eDCS header module 2015 may identifycompression options and may generate extended compression headers. Insome examples, the base station eDCS header module 2015 may cooperatewith the base station compression/decompression module 2070 to compressor decompress data packets in accordance with the compression optionsincluded in the extended compression headers. The base station eDCSheader module 2015, or portions of the base station eDCS header module2015, may include a processor module, or some or all of the functions ofthe base station eDCS header module 2015 may be performed by theprocessor module 2010 or in connection with the processor module 2010.Similarly, the base station compression/decompression module 2070, orportions of the base station compression/decompression module 2070, mayinclude a processor module, or some or all of the functions of the basestation compression/decompression module 2070 may be performed by theprocessor module 2010 or in connection with the processor module 2010.In some examples, the base station eDCS header module 2015 may be anexample of the eDCS header module 1715 or 1815 described with referenceto FIGS. 17 and 18.

FIG. 21 shows a flowchart illustrating a method 2100 for evolved datacompression scheme signaling in accordance with various aspects of thepresent disclosure. The operations of method 2100 may be implemented bya UE 115 or its components as described with reference to FIGS. 1-20.For example, the operations of method 2100 may be performed by theevolved data compression module 910 as described with reference to FIGS.9-12. In some examples, a UE 115 may execute a set of codes to controlthe functional elements of the UE 115 to perform the functions describedbelow. Additionally or alternatively, the UE 115 may perform aspects thefunctions described below using special-purpose hardware.

At block 2105, the UE 115 may receive a compression capability requestrelated to a capability for compressing a payload of a wireless datatransmission as described above with reference to FIGS. 2-4. In certainexamples, the operations of block 2105 may be performed by thecapability request module 1005 as described above with reference to FIG.10.

At block 2110, the UE 115 may identify at least one compressioncapability parameter based on the compression capability request asdescribed above with reference to FIGS. 2-4. In certain examples, theoperations of block 2110 may be performed by the capabilityidentification module 1010 as described above with reference to FIG. 10.

At block 2115, the UE 115 may transmit a compression capability responsebased at least in part on the compression capability request and the atleast one compression capability parameter as described above withreference to FIGS. 2-4. In certain examples, the operations of block2115 may be performed by the capability response module 1015 asdescribed above with reference to FIG. 10.

FIG. 22 shows another flowchart illustrating a method 2200 for evolveddata compression scheme signaling in accordance with various aspects ofthe present disclosure. The operations of method 2200 may be implementedby a UE 115 or its components as described with reference to FIGS. 1-20.For example, the operations of method 2200 may be performed by theevolved data compression module 910 as described with reference to FIGS.9-12. In some examples, a UE 115 may execute a set of codes to controlthe functional elements of the UE 115 to perform the functions describedbelow. Additionally or alternatively, the UE 115 may perform aspects thefunctions described below using special-purpose hardware. The method2200 may incorporate aspects of method 2100 of FIG. 21.

At block 2205, the UE 115 may receive a compression capability requestrelated to a capability for compressing a payload of a wireless datatransmission as described above with reference to FIGS. 2-4. In certainexamples, the operations of block 2205 may be performed by thecapability request module 1005 as described above with reference to FIG.10.

At block 2210, the UE 115 may identify at least one compressioncapability parameter based on the compression capability request asdescribed above with reference to FIGS. 2-4. In certain examples, theoperations of block 2210 may be performed by the capabilityidentification module 1010 as described above with reference to FIG. 10.

At block 2215, the UE 115 may transmit a compression capability responsebased at least in part on the compression capability request and the atleast one compression capability parameter as described above withreference to FIGS. 2-4. In certain examples, the operations of block2215 may be performed by the capability response module 1015 asdescribed above with reference to FIG. 10.

At block 2220, the UE 115 may receive a compression configurationrequest as described above with reference to FIGS. 2-4. In certainexamples, the operations of block 2220 may be performed by thecompression configuration module 1105 as described above with referenceto FIG. 11.

At block 2225, the UE 115 may transmit a compression configurationconfirmation based at least in part on the compression configurationrequest as described above with reference to FIGS. 2-4. In certainexamples, the operations of block 2225 may be performed by thecompression configuration module 1105 as described above with referenceto FIG. 11.

FIG. 23 shows another flowchart illustrating a method 2300 for evolveddata compression scheme signaling in accordance with various aspects ofthe present disclosure. The operations of method 2300 may be implementedby a UE 115 or its components as described with reference to FIGS. 1-20.For example, the operations of method 2300 may be performed by theevolved data compression module 910 as described with reference to FIGS.9-12. In some examples, a UE 115 may execute a set of codes to controlthe functional elements of the UE 115 to perform the functions describedbelow. Additionally or alternatively, the UE 115 may perform aspects thefunctions described below using special-purpose hardware. The method2300 may incorporate aspects of methods 2100, and 2200 of FIGS. 21and/or 22.

At block 2305, the UE 115 may receive a compression capability requestrelated to a capability for compressing a payload of a wireless datatransmission as described above with reference to FIGS. 2-4. In certainexamples, the operations of block 2305 may be performed by thecapability request module 1005 as described above with reference to FIG.10.

At block 2310, the UE 115 may identify at least one compressioncapability parameter based on the compression capability request asdescribed above with reference to FIGS. 2-4. In certain examples, theoperations of block 2310 may be performed by the capabilityidentification module 1010 as described above with reference to FIG. 10.

At block 2315, the UE 115 may transmit a compression capability responsebased at least in part on the compression capability request and the atleast one compression capability parameter as described above withreference to FIGS. 2-4. In certain examples, the operations of block2315 may be performed by the capability response module 1015 asdescribed above with reference to FIG. 10.

At block 2320, the UE 115 may receive a compressed packet based at leastin part on the compression capability response as described above withreference to FIGS. 2-4. The compressed packet comprises one or moreextended compression header fields indicating at least one of: acompression context reset request, a compression disable requestassociated with a number of subsequent packets, a compression contextsynchronization indication, a compression context freeze request, amulti-part compression indicator associated with a plurality ofcompression contexts, or a compression metadata indicator. In certainexamples, the operations of block 2320 may be performed by thedecompression module 1115 as described above with reference to FIG. 11.

FIG. 24 shows another flowchart illustrating a method 2400 for evolveddata compression scheme signaling in accordance with various aspects ofthe present disclosure. The operations of method 2400 may be implementedby a UE 115 or its components as described with reference to FIGS. 1-20.For example, the operations of method 2400 may be performed by theevolved data compression module 910 as described with reference to FIGS.9-12. In some examples, a UE 115 may execute a set of codes to controlthe functional elements of the UE 115 to perform the functions describedbelow. Additionally or alternatively, the UE 115 may perform aspects thefunctions described below using special-purpose hardware. The method2400 may incorporate aspects of methods 2100, 2200, and/or 2300 of FIGS.21-23.

At block 2405, the UE 115 may receive a compression capability requestrelated to a capability for compressing a payload of a wireless datatransmission as described above with reference to FIGS. 2-4. In certainexamples, the operations of block 2405 may be performed by thecapability request module 1005 as described above with reference to FIG.10.

At block 2410, the UE 115 may identify at least one compressioncapability parameter based on the compression capability request asdescribed above with reference to FIGS. 2-4. In certain examples, theoperations of block 2410 may be performed by the capabilityidentification module 1010 as described above with reference to FIG. 10.

At block 2415, the UE 115 may transmit a compression capability responsebased at least in part on the compression capability request and the atleast one compression capability parameter as described above withreference to FIGS. 2-4. In certain examples, the operations of block2415 may be performed by the capability response module 615 as describedabove with reference to FIG. 10.

At block 2420, the UE 115 may transmit a compression enable request or acompression disable request based at least in part on at least one of aprocessing limitation, a traffic type, or a determination that aresource grant volume is sufficient to clear an uncompressed memorybuffer during one or more periodic intervals as described above withreference to FIGS. 2-4. In certain examples, the operations of block2420 may be performed by the compression enable/disable module 1140 asdescribed above with reference to FIG. 11.

FIG. 25 shows another flowchart illustrating a method 2500 for evolveddata compression scheme signaling in accordance with various aspects ofthe present disclosure. The operations of method 2500 may be implementedby a base station 105 or its components as described with reference toFIGS. 1-20. For example, the operations of method 2500 may be performedby the base station evolved data compression module 1310 as describedwith reference to FIGS. 13-16. In some examples, a base station 105 mayexecute a set of codes to control the functional elements of the basestation 105 to perform the functions described below. Additionally oralternatively, the base station 105 may perform aspects the functionsdescribed below using special-purpose hardware. The method 2500 mayincorporate aspects of methods 2100, 2200, 2300, 2400 and/or 2500 ofFIGS. 21-25.

At block 2505, the base station 105 may transmit a compressioncapability request related to a capability for compressing a payload ofa wireless data transmission as described above with reference to FIGS.2-4. In certain examples, the operations of block 2505 may be performedby the BS capability request module 1405 as described above withreference to FIG. 14.

At block 2510, the base station 105 may receive a compression capabilityresponse based at least in part on the compression capability request asdescribed above with reference to FIGS. 2-4. In certain examples, theoperations of block 2510 may be performed by the BS capability responsemodule 1410 as described above with reference to FIG. 14.

At block 2515, the base station 105 may select a compressionconfiguration based at least in part on the compression capabilityresponse as described above with reference to FIGS. 2-4. In certainexamples, the operations of block 2515 may be performed by the BScompression configuration module 1415 as described above with referenceto FIG. 14.

FIG. 26 shows another flowchart illustrating a method 2600 for evolveddata compression scheme signaling in accordance with various aspects ofthe present disclosure. The operations of method 2600 may be implementedby a base station 105 or its components as described with reference toFIGS. 1-20. For example, the operations of method 2600 may be performedby the base station evolved data compression module 1310 as describedwith reference to FIGS. 13-16. In some examples, a base station 105 mayexecute a set of codes to control the functional elements of the basestation 105 to perform the functions described below. Additionally oralternatively, the base station 105 may perform aspects the functionsdescribed below using special-purpose hardware. The method 2600 mayincorporate aspects of methods 2100, 2200, 2300, 2400, and/or 2500 ofFIGS. 21-25.

At block 2605, the base station 105 may transmit a compressioncapability request related to a capability for compressing a payload ofa wireless data transmission as described above with reference to FIGS.2-4. In certain examples, the operations of block 2605 may be performedby the BS capability request module 1405 as described above withreference to FIG. 14.

At block 2610, the base station 105 may receive a compression capabilityresponse based at least in part on the compression capability request asdescribed above with reference to FIGS. 2-4. In certain examples, theoperations of block 2610 may be performed by the BS capability responsemodule 1410 as described above with reference to FIG. 14.

At block 2615, the base station 105 may select a compressionconfiguration based at least in part on the compression capabilityresponse as described above with reference to FIGS. 2-4. In certainexamples, the operations of block 2615 may be performed by the BScompression configuration module 1415 as described above with referenceto FIG. 14.

At block 2620, the base station 105 may transmit a compressionconfiguration request based at least in part on the selected compressionconfiguration as described above with reference to FIGS. 2-4. In certainexamples, the operations of block 2620 may be performed by the BScompression configuration module 1415-a as described above withreference to FIG. 12.

At block 2625, the base station 105 may receive a compressionconfiguration confirmation based at least in part on the compressionconfiguration request as described above with reference to FIGS. 2-4. Incertain examples, the operations of block 2625 may be performed by theBS compression configuration module 1415-a as described above withreference to FIG. 12.

FIG. 27 is a flow chart illustrating an example of a method for wirelesscommunication, in accordance with aspects of the present disclosure. Forclarity, the method 2700 is described below with reference to aspects ofone or more of the UEs 115 or base stations 105 or their componentsdescribed with reference to FIGS. 1-20. In some examples, a UE or basestation may execute one or more sets of codes to control the functionalelements of the UE or base station to perform the functions describedbelow. Additionally or alternatively, the UE or base station may performone or more of the functions described below using special-purposehardware.

At block 2705, the method 2700 may include identifying a compressionoption associated with a wireless communication session, wherein thecompression option is associated with at least a compression context inthe wireless communication session. The operations at block 2705 may beperformed using the compression option module 1825 described withreference to FIG. 18.

At block 2710, the method 2700 may include generating a compressionheader for a data packet, wherein the compression header comprises acompression scheme portion that identifies the compression option. Theoperations at block 2710 may be performed using the extended compressionheader module 1830 described with reference to FIG. 18.

At block 2715, the method 2700 may include transmitting the compressionheader and data packet during the wireless communication session. Theoperations at block 2715 may be performed using the transmitter module1720, 1820 of FIGS. 17 and 18.

Thus, the method 2700 may provide for wireless communication. It shouldbe noted that the method 2700 is just one implementation and that theoperations of the method 2700 may be rearranged or otherwise modifiedsuch that other implementations are possible.

FIG. 28 is a flow chart illustrating an example of a method for wirelesscommunication, in accordance with aspects of the present disclosure. Forclarity, the method 2800 is described below with reference to aspects ofone or more of the UEs 115 or base stations 105 or their componentsdescribed with reference to FIGS. 1-20. In some examples, a UE or basestation may execute one or more sets of codes to control the functionalelements of the UE or base station to perform the functions describedbelow. Additionally or alternatively, the UE or base station may performone or more of the functions described below using special-purposehardware.

At block 2805, the method 2800 may include identifying a compressionoption associated with a wireless communication session. The operationsat block 2805 may be performed using the compression option module 1825described with reference to FIG. 18.

At block 2810, the method 2800 may include conveying, via thecompression option, a compression context identification (ID) whichidentifies the compression context applied to one or more portions ofthe data packet. The operations at block 2810 may be performed using thecompression option module 1825 described with reference to FIG. 18 andthe transmitter 1720, 1820 of FIGS. 17 and 18.

At block 2815, the method 2800 may include indicating to a receiver, viathe compression option, to reset a compression scheme to a compressioncontext ID. The operations at block 2815 may be performed using thecompression option module 1825 described with reference to FIG. 18 andthe transmitter 1720, 1820 of FIGS. 17 and 18.

At block 2820, the method 2800 may include indicating to a receiver, viathe compression option, to store the compression context using thecompression context ID. The operations at block 2820 may be performedusing the compression option module 1825 described with reference toFIG. 18 and the transmitter 1720, 1820 of FIGS. 17 and 18.

At block 2825, the method 2800 may include indicating to a receiver, viathe compression option, to apply the compression context ID toadditional data packets transmitted subsequent to the transmission ofthe data packet without updating the compression context. The operationsat block 2825 may be performed using the compression option module 1825described with reference to FIG. 18 and the transmitter 1720, 1820 ofFIGS. 17 and 18.

At block 2830, the method 2800 may include indicating, via thecompression option, that the compression context ID applies to a part ofan un-compressed portion of the data packet. The operations at block2830 may be performed using the compression option module 1825 describedwith reference to FIG. 18 and the transmitter 1720, 1820 of FIGS. 17 and18.

Thus, the method 2800 may provide for wireless communication. It shouldbe noted that the method 2800 is just one implementation and that theoperations of the method 2800 may be rearranged or otherwise modifiedsuch that other implementations are possible.

FIG. 29 is a flow chart illustrating an example of a method for wirelesscommunication, in accordance with aspects of the present disclosure. Forclarity, the method 2900 is described below with reference to aspects ofone or more of the UEs 115 or base stations 185 described with referenceto FIGS. 1-20. In some examples, a UE 115 or base station 185 mayexecute one or more sets of codes to control the functional elements ofthe UE or base station to perform the functions described below.Additionally or alternatively, the UE or base station may perform one ormore of the functions described below using special-purpose hardware.

At block 2905, the method 2900 may include identifying a compressionoption associated with a wireless communication session. The operationsat block 2905 may be performed using the compression option module 1825described with reference to FIG. 18.

At block 2910, the method 2900 may include indicating, via thecompression option, that at least one data packet transmitted subsequentto the transmission of the data packet will not include the compressionheader. The operations at block 2910 may be performed using thecompression option module 1825 described with reference to FIG. 1 andthe transmitter 1720, 1820 of FIGS. 17 and 18.

At block 2915, the method 2900 may include indicating, via thecompression option, that current and subsequent data packets will notinclude a compression metadata. The operations at block 2915 may beperformed using the compression option module 1825 described withreference to FIG. 18 and the transmitter 1720, 1820 of FIGS. 17 and 18.

Thus, the method 2900 may provide for wireless communication. It shouldbe noted that the method 2900 is just one implementation and that theoperations of the method 2900 may be rearranged or otherwise modifiedsuch that other implementations are possible.

Thus, methods 2100, 2200, 2300, 2400, 2500, 2600, 2700, 2800 and 2900may provide for evolved data compression scheme signaling. It should benoted that methods 2100, 2200, 2300, 2400, 2500, 2600, 2700, 2800 and2900 describe possible implementations, and that the operations and thesteps may be rearranged or otherwise modified such that otherimplementations are possible. In some examples, aspects from two or moreof the methods 2100, 2200, 2300, 2400, 2500, 2600, 2700, 2800 and 2900may be combined.

The detailed description set forth above in connection with the appendeddrawings describes exemplary embodiments and does not represent all theembodiments that may be implemented or that are within the scope of theclaims. The term “exemplary” used throughout this description means“serving as an example, instance, or illustration,” and not “preferred”or “advantageous over other embodiments.” The detailed descriptionincludes specific details for the purpose of providing an understandingof the described techniques. These techniques, however, may be practicedwithout these specific details. In some instances, well-known structuresand devices are shown in block diagram form in order to avoid obscuringthe concepts of the described embodiments.

Information and signals may be represented using any of a variety ofdifferent technologies and techniques. For example, data, instructions,commands, information, signals, bits, symbols, and chips that may bereferenced throughout the above description may be represented byvoltages, currents, electromagnetic waves, magnetic fields or particles,optical fields or particles, or any combination thereof.

The various illustrative blocks and modules described in connection withthe disclosure herein may be implemented or performed with ageneral-purpose processor, a DSP, an ASIC, an FPGA or other programmablelogic device, discrete gate or transistor logic, discrete hardwarecomponents, or any combination thereof designed to perform the functionsdescribed herein. A general-purpose processor may be a microprocessor,but in the alternative, the processor may be any conventional processor,controller, microcontroller, or state machine. A processor may also beimplemented as a combination of computing devices (e.g., a combinationof a DSP and a microprocessor, multiple microprocessors, one or moremicroprocessors in conjunction with a DSP core, or any other suchconfiguration).

The functions described herein may be implemented in hardware, softwareexecuted by a processor, firmware, or any combination thereof. Ifimplemented in software executed by a processor, the functions may bestored on or transmitted over as one or more instructions or code on acomputer-readable medium. Other examples and implementations are withinthe scope of the disclosure and appended claims. For example, due to thenature of software, functions described above can be implemented usingsoftware executed by a processor, hardware, firmware, hardwiring, orcombinations of any of these. Features implementing functions may alsobe physically located at various positions, including being distributedsuch that portions of functions are implemented at different physicallocations. Also, as used herein, including in the claims, “or” as usedin a list of items (for example, a list of items prefaced by a phrasesuch as “at least one of” or “one or more of”) indicates an inclusivelist such that, for example, a phrase referring to “at least one of” alist of items refers to any combination of those items, including singlemembers. As an example, “at least one of: A, B, or C” is intended tocover A, B, C, A-B, A-C, B-C, and A-B-C., as well as any combinationwith multiples of the same element (e.g., A-A, A-A-A, A-A-B, A-A-C,A-B-B, A-C-C, B-B, B-B-B, B-B-C, C-C, and C-C-C or any other ordering ofA, B, and C).

As used herein, the phrase “based on” shall not be construed as areference to a closed set of conditions. For example, an exemplary stepthat is described as “based on condition A” may be based on both acondition A and a condition B without departing from the scope of thepresent disclosure. In other words, as used herein, the phrase “basedon” shall be construed in the same manner as the phrase “based at leastin part on.”

Computer-readable media includes both non-transitory computer storagemedia and communication media including any medium that facilitatestransfer of a computer program from one place to another. Anon-transitory storage medium may be any available medium that can beaccessed by a general purpose or special purpose computer. By way ofexample, and not limitation, non-transitory computer-readable media cancomprise RAM, ROM, electrically erasable programmable read only memory(EEPROM), compact disk (CD) ROM or other optical disk storage, magneticdisk storage or other magnetic storage devices, or any othernon-transitory medium that can be used to carry or store desired programcode means in the form of instructions or data structures and that canbe accessed by a general-purpose or special-purpose computer, or ageneral-purpose or special-purpose processor. Also, any connection isproperly termed a computer-readable medium. For example, if the softwareis transmitted from a website, server, or other remote source using acoaxial cable, fiber optic cable, twisted pair, digital subscriber line(DSL), or wireless technologies such as infrared, radio, and microwave,then the coaxial cable, fiber optic cable, twisted pair, DSL, orwireless technologies such as infrared, radio, and microwave areincluded in the definition of medium. Disk and disc, as used herein,include CD, laser disc, optical disc, digital versatile disc (DVD),floppy disk and Blu-ray disc where disks usually reproduce datamagnetically, while discs reproduce data optically with lasers.Combinations of the above are also included within the scope ofcomputer-readable media.

The previous description of the disclosure is provided to enable aperson skilled in the art to make or use the disclosure. Variousmodifications to the disclosure will be readily apparent to thoseskilled in the art, and the generic principles defined herein may beapplied to other variations without departing from the scope of thedisclosure. Thus, the disclosure is not to be limited to the examplesand designs described herein but is to be accorded the broadest scopeconsistent with the principles and novel features disclosed herein.

Techniques described herein may be used for various wirelesscommunications systems such as code division multiple access (CDMA),time division multiple access (TDMA), frequency division multiple access(FDMA), orthogonal frequency division multiple access (OFDMA), singlecarrier frequency division multiple access (SC-FDMA), and other systems.The terms “system” and “network” are often used interchangeably. A CDMAsystem may implement a radio technology such as CDMA2000, UniversalTerrestrial Radio Access (UTRA), etc. CDMA2000 covers IS-2000, IS-95,and IS-856 standards. IS-2000 Releases 0 and A are commonly referred toas CDMA2000 1X,1X, etc. IS-856 (TIA-856) is commonly referred to asCDMA2000 1x EV-DO, High Rate Packet Data (HRPD), etc. UTRA includesWideband CDMA (WCDMA) and other variants of CDMA. A TDMA system mayimplement a radio technology such as Global System for MobileCommunications (GSM). An OFDMA system may implement a radio technologysuch as Ultra Mobile Broadband (UMB), Evolved UTRA (E-UTRA), IEEE 802.11(Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Flash-OFDM, etc. UTRA andE-UTRA are part of Universal Mobile Telecommunications system (UMTS).3GPP Long Term Evolution (LTE) and LTE-Advanced (LTE-A) are new releasesof Universal Mobile Telecommunications System (UMTS) that use E-UTRA.UTRA, E-UTRA, UMTS, LTE, LTE-A, and Global System for Mobilecommunications (GSM) are described in documents from an organizationnamed “3rd Generation Partnership Project” (3GPP). CDMA2000 and UMB aredescribed in documents from an organization named “3rd GenerationPartnership Project 2” (3GPP2). The techniques described herein may beused for the systems and radio technologies mentioned above as well asother systems and radio technologies. The description above, however,describes an LTE system for purposes of example, and LTE terminology isused in much of the description above, although the techniques areapplicable beyond LTE applications.

What is claimed is:
 1. A method of communication at a wireless device,comprising: receiving, from a first device, a compression capabilityrequest requesting an indication of a capability of the wireless devicefor compressing a payload of a wireless data transmission; identifying,by the wireless device, a compression capability parameter based on thecompression capability request and the capability of the wirelessdevice, wherein the compression capability parameter is one of uplinkalgorithm information, downlink algorithm information, a compressionrate supported by the wireless device, a compressor context memory size,or a prefill configuration for a compressor context memory;transmitting, to the first device and in response to the compressioncapability request, a compression capability response that includes aheader that conveys the compression capability parameter, thecompression capability response indicating one or more capabilities ofthe wireless device and allowing the first device to select acompression configuration based at least in part on the compressioncapability parameter; and receiving, from the first device, acompression configuration request based at least in part on thecompression capability response, the compression configuration requestindicating a compression context identity (ID) that is saved across aplurality of radio resource control (RRC) connections.
 2. The method ofclaim 1, further comprising: transmitting a compression configurationconfirmation or rejection based at least in part on the compressionconfiguration request.
 3. The method of claim 1, further comprising:transmitting and receiving a compressed packet based at least in part onthe compression capability response.
 4. The method of claim 3, whereinthe compressed packet comprises one or more extended compression headerfields indicating at least one of: a compression context reset request,a compression disable request associated with a number of subsequentpackets, a compression context synchronization indication, a compressioncontext freeze request, a multi-part compression indicator associatedwith a plurality of compression contexts, or a compression metadataindicator.
 5. The method of claim 4, further comprising: transmitting acontext identification (ID) save confirmation request; and receiving acontext ID save confirmation.
 6. The method of claim 1, furthercomprising: transmitting a compression control message.
 7. The method ofclaim 6, wherein transmitting the compression control message comprises:transmitting the compression control message on a high priority radiobearer.
 8. The method of claim 6, wherein the compression controlmessage is based at least in part on a determination that an amount ofavailable wireless device processing resources is below a threshold, orbased on a determination that the wireless device has failed todecompress or decode a number of packets.
 9. The method of claim 6,wherein the compression control message comprises at least one of acompression state indication, a compression scope indication, a datacompression threshold, a compression enable/disable indication, acompressed packet ratio, or a context ID reset request.
 10. The methodof claim 1, further comprising: transmitting a compression statusindication.
 11. The method of claim 10, wherein the compression statusindication comprises at least one of a ciphered packet data convergenceprotocol (PDCP) control protocol data unit (PDU) type, an uncipheredPDCP control PDU type, a sequence number, or a compressionenable/disable indication.
 12. The method of claim 10, whereintransmitting the compression status indication comprises: disabling orenabling compression on a radio bearer; and transmitting the compressionstatus indication after a last or before a first compressed dataprotocol data unit (PDU) is transmitted.
 13. The method of claim 1,further comprising: transmitting a compression enable request or acompression disable request based at least in part on at least one of aprocessing limitation, a traffic type, or a determination that aresource grant volume is sufficient to clear an uncompressed memorybuffer during one or more periodic intervals.
 14. The method of claim 1,wherein the compression capability parameter comprises a compressionrate support parameter or a compression context prefill configuration.15. The method of claim 1, further comprising: disabling a PDCP discardtimer based at least in part on the compression capability request. 16.The method of claim 1, further comprising: storing a compressed versionof a packet; storing an uncompressed version of the packet; andresetting a context ID based on the uncompressed version of the packet.